Page MenuHomePhabricator

[ELF][AArch64] Correct relocation codes for R_<CLS>_PLT32

Authored by psmith on Jun 8 2020, 10:00 AM.



The relocation codes for R_<CLS>_PLT32 are incorrectly in the dynamic relocation range that starts at 1024 for AArch64 and 180 for AArch64_32. Correct these codes so that they start at the next available static relocation code below TLS. The R_<CLS>_PLT32 description is currently in unpublished draft so this change corrects LLVM to match the values that will appear in the next release of ELF for the 64-bit Arm Architecture document.

Diff Detail

Event Timeline

psmith created this revision.Jun 8 2020, 10:00 AM
pcc added inline comments.Jun 8 2020, 10:40 AM

Shouldn't it be in the range [0x100..0x200)? This value is in the range used for TLS relocations, [0x200..0x300).


Likewise. It looks like [0x00..0x50) is the range for the aarch64_32 non-TLS relocations.

Thanks for the comments. When I made the change I looked at:

Static relocation codes for ELF64 object files begin at (257); dynamic ones at (1024). Both (0) and (256) should be accepted as values of R_AARCH64_NONE, the null relocation.
Static relocation codes for ELF32 object files begin at [1]; dynamic ones at [180].

I couldn't find anything about a TLS range, but it looks like there is one being observed even if it isn't explicitly called out. Let me know if you've spotted it?

I'll check with my colleagues tomorrow as I'll need to get the ABI change approved before updating here. My preference would be to move before the TLS relocations but it is probably not the end of the world as I don't think that there is any tool that could guarantee the TLS relocations were in a certain range to make a simpler isTLSReloc check.

psmith updated this revision to Diff 269545.Jun 9 2020, 8:08 AM
psmith edited the summary of this revision. (Show Details)

I've moved the codes below the block of relocations representing TLS.

MaskRay accepted this revision.Jun 9 2020, 8:27 AM


This revision is now accepted and ready to land.Jun 9 2020, 8:27 AM
This revision was automatically updated to reflect the committed changes.