[PATCH] D28811: [LLD][ARM][Mips] Move createThunks() after scanRelocs()
Peter Smith via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jan 17 09:18:38 PST 2017
peter.smith created this revision.
Herald added subscribers: rengolin, aemerson.
This is the first of at least 3 patches to implement Thunks as synthetic sections. I have a prototype that does this but it is a bit too large to review in one go. The intended patches are:
1.) Move createThunks() past scanRelocs (this patch)
2.) Add ability to add local symbols (with same name) to Synthetic Sections
3.) Implement Thunks as synthetic sections
The change moves the createThunks() function after scanRelocs() and reimplements it to scan the relocations created by scanRelocs. This will permit the relocation to be retargeted to a local symbol defined by the Thunk when Thunks are synthetic sections.
As a result of moving createThunks() after scanRelocs() the addition of thunks may alter the OutSecOff of InputSections after the Thunk. This is resolved by calling assignOffsets() to recalculate them. From looking at the code this could be a problem if there are thunks in the same OutputSection as a dynamic relocation. Dynamic relocations remember the OutputSectionOffset from scanRelocs(). I think that this would only happen if there was a dynamic relocation in an executable OutputSection with Thunks which I think would be hard to do by accident. If this is too much of a risk I think that it is possible (in a separate patch) to make the ZI created by CopyRelocs synthetic sections. This is the one remaining use of a dynamic relocation that isn't relative to a (synthetic) InputSection. If this were converted I think we could describe all dynamic relocations as an offset from an InputSection so late creation of content such as Thunks wouldn't be a problem.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9690 bytes
Desc: not available
More information about the llvm-commits