This is "Bug 34836 - --gc-sections remove relocations from --emit-relocs",
When --emit-relocs is used, LLD currently always drops SHT_REL[A] sections from
output if --gc-sections is present. Patch fixes the issue.
Differential D38724
[ELF] - Do not collect SHT_REL[A] sections unconditionally when --gc-sections and --emit-relocs used together. grimar on Oct 10 2017, 6:16 AM. Authored by
Details
This is "Bug 34836 - --gc-sections remove relocations from --emit-relocs", When --emit-relocs is used, LLD currently always drops SHT_REL[A] sections from
Diff Detail
Event Timeline
Comment Actions
Comment Actions
Comment Actions I'm not convinced. It may fail on some assert, or it may not work well with the current code, but my comment was from a more high-level design point of view. I'd like you to also think at high-level instead of tracing the existing code to explain why your patch needs to be in the current design. You are writing a mark-sweep garbage collector. In the mark phase, you mark all root objects as alive, and mark all reachable objects as alive. In this phase, the knowledge of whether some object is a gc root or not is needed only at the beginning of the algorithm. If not, it is probably a sign that something is not correct. If that's the case, we need to find a design flaw and fix it, instead of writing more code on top of a wrong assumption. Did you take a look why we had the assert? Can you explain why the assertion is there? I wonder if it makes sense. Comment Actions Sure. We have is as a guard for internal logic of MergeInputSection I believe and it can easily be removed. Comment Actions This change works on my case, but it names the reloc sections it emits based on the first input section in the output section being relocated rather than on the output section itself.
Comment Actions I am not sure that is an issue as SHT_RELA section name should be insignificant here, but it I would probably fix that to make output nicer and be consistent with GNU linkers. I'll take a look.
Comment Actions Well, it doesn't seems like https://reviews.llvm.org/D38996 is particularly a good change. Somewhat neutral, but I wouldn't land that. |