[PATCH] D26029: [LLD][ARM] ARM IRELATIVE relocations are in rel.dyn

[Peter Smith via llvm-commits]

peter.smith added a comment.

As far as I know there isn't any existing effort to fix the loader as the loader will happily will work with gold and bfd as they are Today. Even if the loader is modified there will be a delay until Linux distributions pick it up as the glibc release cycle can be quite long (ld.so is part of glibc) and many existing installations that will remain on the old library. I think it is worth at least reporting to glibc, but practically speaking I think we'll have to follow the existing conventions.

I think merging the .got and .got.plt solves one of the cases, whether to put the .got entry into .got.plt or .got, but it doesn't solve the problem that the relocation will need to go into .rel.dyn and not .rel.plt, and that is the majority of the mess. Unfortunately we can't merge .rel.plt and .rel.dyn so most of the special cases will still exist.

I can have a go at adding some helper function to see if I can clear up the main code path.

Turning the problem on its head I did consider whether it would be worth making all the other Targets use rel.dyn rather than .rel.plt, this would unify the implementations using the ARM way. However it seems like other linker's like ld don't do this on Targets like x86 and try to avoid doing so where possible so I'm reluctant to do this given how poorly specified all this is.

As an aside while looking into ifunc support in other linkers I came across: https://sourceware.org/bugzilla/show_bug.cgi?id=13302 which makes sure IRELATIVE relocations are always sorted to appear after non IRELATIVE relocations, this avoids corner cases where the IFUNC resolver refers to a PLT entry that hasn't been relocated yet. I don't think that lld does this at the moment so we would presumably be vulnerable to the same corner case.


https://reviews.llvm.org/D26029