These are sometimes generated by tail-call optimizations and had not been properly handled.
ruiu MaskRay shankare bcain kparzysz espindola
- rGaca5d395d541: [lld][Hexagon] Support PLT relocation R_HEX_B15_PCREL_X/R_HEX_B9_PCREL_X
rLLD374052: [lld][Hexagon] Support PLT relocation R_HEX_B15_PCREL_X/R_HEX_B9_PCREL_X
rL374052: [lld][Hexagon] Support PLT relocation R_HEX_B15_PCREL_X/R_HEX_B9_PCREL_X
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;
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.
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.
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.
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.
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.
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.