[PATCH] D52830: [ELF] - Set sh_info and sh_link for .rela.plt sections.
Ed Maste via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Oct 9 07:52:57 PDT 2018
emaste added a comment.
This change LGTM.
================
Comment at: ELF/SyntheticSections.cpp:1496-1497
// dynamic symbol and we don't need a dynamic symbol table. If that
- // is the case, just use 0 as the link.
- getParent()->Link =
- In.DynSymTab ? In.DynSymTab->getParent()->SectionIndex : 0;
+ // is the case, just use the index of the regular symbol table section
+ // as the link to suppress the warnings reported by GNU tools like readelf.
+ getParent()->Link = In.DynSymTab ? In.DynSymTab->getParent()->SectionIndex
----------------
grimar wrote:
> ruiu wrote:
> > You do that not because GNU tools complain but because that's the right thing to do according to ELF spec, no?
> I would not say it is clear to me that it is required.
> Spec says about `sh_link` that it contains "The section header index of the associated symbol table. ".
> In the case of `.rela.iplt` we can live without the symbol table. In that case, this association does not make sense.
>
> Spec does not say what should we do when there is no symbol table associated. With the same success, it probably
> could be an empty dynamic section we could create for consistency.
>
> Or, another example, with `-strip-all` we do not create the `.symtab`. And tools would complain again I guess,
> though I see nothing obviously wrong with that scenario.
>
> Perhaps I am overthinking. I'll shorten the comment.
The issue I encountered was with `sh_info` where according to the ELF spec I believe this change is a correctness fix (and did not trigger warnings from GNU tools anyhow).
For `sh_link` in an ifunc-using statically-linked binary I think it is arguable that this change is only to appease GNU readelf.
https://reviews.llvm.org/D52830
More information about the llvm-commits
mailing list