This is an archive of the discontinued LLVM Phabricator instance.

R_HEX_B15_PCREL_X/R_HEX_B9_PCREL_X can be in shared objects
ClosedPublic

Authored by sidneym on Aug 21 2019, 10:02 AM.

Diff Detail

Event Timeline

sidneym created this revision.Aug 21 2019, 10:02 AM
Herald added a project: Restricted Project. · View Herald Transcript

I sent a request to download hexagon-application-binary-interface-specification.zip a few days ago but I still don't get a copy...

The only information in the Internet about R_HEX_B15_PCREL_X is probably this patch now.. I'd say this is very inconvenient for anyone who'd like to contribute to verify the correctness. Since there is not any reference available, I can only guess.

What do the _X relocation types represent? Why are some R_PLT_PC while the others are R_PC?

case R_HEX_B9_PCREL:
case R_HEX_B13_PCREL:
case R_HEX_B15_PCREL:
case R_HEX_32_PCREL:
  return R_PC;
case R_HEX_6_PCREL_X:
case R_HEX_B9_PCREL_X:
case R_HEX_B15_PCREL_X:
case R_HEX_B22_PCREL:
case R_HEX_PLT_B22_PCREL:
case R_HEX_B22_PCREL_X:
case R_HEX_B32_PCREL_X:
  return R_PLT_PC;
bcain added a comment.Aug 21 2019, 8:00 PM

I sent a request to download hexagon-application-binary-interface-specification.zip a few days ago but I still don't get a copy...

The only information in the Internet about R_HEX_B15_PCREL_X is probably this patch now.. I'd say this is very inconvenient for anyone who'd like to contribute to verify the correctness. Since there is not any reference available, I can only guess.

What do the _X relocation types represent? Why are some R_PLT_PC while the others are R_PC?

The _X relocations are for the immediate extenders.

ruiu added a comment.Aug 21 2019, 9:05 PM

I generally trust Sid for the Hexagon port of lld, and because this patch seems like fixing thinko in the Hexagon port, I'm fine with this patch. If there's a relocation for Hexagon that doesn't fall into an existing category, we'll need a technical specification (or at least an informal technical document) to accept it, though.

R_PLT_PC and R_PC are mutually convertible.

  • R_PLT_PC -> R_PC: if the target symbol is non-preemptable, an R_PLT_PC gets optimized to an R_PC, and the R_PC is considered a link-time constant.
  • R_PC -> R_PLT_PC: for non-pic code pointing to an external function, an R_PC behaves as an R_PLT_PC, however, it will trigger the creation of a canonical PLT.

Generally, R_PC should be used if the target symbol may be STT_OBJECT, otherwise R_PLT_PC is preferred (because it can prevent a canonical PLT). I don't have a specification now. From the two lists of R_PC and R_PLT_PC, I guess there might be some problems so I asked for a clarification.

sidneym updated this revision to Diff 216632.Aug 22 2019, 8:31 AM
sidneym marked an inline comment as done.

I accidentally moved R_HEX_6_PCREL_X, I only intended to update R_HEX_B15_PCREL_X/R_HEX_B9_PCREL_X.

Generally, the non-extended branch relocations are never found in objects but one could manually generate them. The rules work like this:

  • if (p0) jump external // The assembler picks the relocation, either R_HEX_B15_PCREL or R_HEX_B15_PCREL_X in practice when the label is external it will pick the _X version
  • if (p0) jump #external // The programmer says I want the non-extended version, R_HEX_B15_PCREL will be used.
  • if (p0) jump ##external // The programmer says I want the extended version, R_HEX_B15_PCREL_X will be used.

Since it is possible for the assembly programmer to demand the non-extended versions of B9/B13/B15 they could also be moved.

Thank you for making it public!

The test here is for the -shared case. STB_GLOBAL STV_DEFAULT symbols are preemptable in an object file, so R_PLT_PC relocations to them can not be optimized to R_PC even if the definitions are local.

Do you need a -no-pie or -pie test that checks if the target symbol is a locally defined symbol, it can be optimized to not use the PLT?

Other than the test request (or clarification if this ELF rule is not applicable on Hexagon), this patch looks good to me.

lld/test/ELF/hexagon-shared.s
61–62

Can some of the PLT: checks be changed to PLT-NEXT:? That improves the error messages of FileCheck. It will make layout change easier which can change section addresses. There are several layout changes in the past, e.g. making .gnu.hash enabled by default, reordering readonly sections before .text, allowing PT_LOAD segments to overlap (D66542), etc. Many people are unfamiliar with Hexagon and thus any -NEXT: convenience here will be very useful.

sidneym updated this revision to Diff 222181.Sep 27 2019, 10:45 AM

Updated testcase.

Local jumps are almost always resolved by the assembler unless -mno-fixup is used.

There are no specific rules regarding which relocations are preemptible.

If there are some behaviors you would like me to model on hexagon let me know which tests and I will take a look at them and try to add Hexagon versions.

Thanks,

sidneym marked an inline comment as done.Oct 2 2019, 6:25 AM

If PLT is needed, you may want to take a look at riscv-plt.s ppc32-abs-pic.s ppc32-call-stub-pic.s. They demonstrate some properties that should be checked: dynamic relocations, PLT instruction sequences, contents of dynamic section, etc.

sidneym updated this revision to Diff 223645.Oct 7 2019, 2:37 PM

Add a new test similar to riscv-plt.s. Update hexagon-shared.s to test -Bsymbolic and .hidden.

MaskRay accepted this revision.Oct 8 2019, 2:39 AM
This revision is now accepted and ready to land.Oct 8 2019, 2:39 AM
This revision was automatically updated to reflect the committed changes.