[lld] r313372 - Keep some relocations with undefined weak symbols.
Rafael Avila de Espindola via llvm-commits
llvm-commits at lists.llvm.org
Thu Oct 12 09:56:12 PDT 2017
Rafael Avila de Espindola <rafael.espindola at gmail.com> writes:
> BTW, I have tried to change this to always create a dynamic symbol table
> first and remove it in removeUnusedSyntheticSections if empty.
>
> A change is that we would have a dynamic symbol table on otherwise
> static programs if they had an undefined weak symbol. As far as I can
> tell, that is harmless.
>
> An annoying case is what to do with _DYNAMIC. The current patch has two
> passes over the symbols. First checking if we need anything in the
> dynamic symbol table. After that pass removeUnusedSyntheticSections can
> remove the dynamic sections (.dynsym, .dynamic, etc) and we can decide
> if _DYNAMIC should be added to the staic symbol table.
>
> A wip patch is attached. Does anyone think this is a good idea?
>
> And yet another option is to always have a .dynsym table. The extra cost
> on static binaries would be really small, so this is tempting.
I think I found a case that would not work with both options.
In both cases the program
.weak foo
.global _start
_start:
bl foo
Would end up with a dynamic symbol table and a relocation to foo. That
is exactly what we want if a dynamic linker is to find foo, but I think
it would break aarch64 programs that expect not having a dynamic linker.
The issue is that on aarch64 (and arm), a call to a undefined weak
symbol is required to turn into a nop. If we have a dynamic symbol table
the above is a plt call, and we need the dynamic linker to write a value
to the .got.
This means we need to known if a dynamic linker will be present or
not. That is what HasDynSymTab is.
The last version of the patch before I noticed the above issues is
attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.diff
Type: text/x-patch
Size: 13077 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171012/6920f302/attachment.bin>
-------------- next part --------------
Cheers,
Rafael
More information about the llvm-commits
mailing list