[PATCH] D36579: [ELF] - Do not fail when set versions for linkerscript's symbol aliases

Simon Atanasyan via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 13 03:55:40 PDT 2017


atanasyan added a comment.

In https://reviews.llvm.org/D36579#869328, @grimar wrote:

> In https://reviews.llvm.org/D36579#868106, @atanasyan wrote:
>
> > MIPS part is LGTM.
> >
> > It's interesting that _gp_disp and __gnu_local_gp have incorrect binding and visibility for so long time. I will fix that later.
>
>
> Thanks for looking. It only happens for `_gp_disp` and `__gnu_local_gp` if them are assigned from script to something, I guess that is just a rare case.
>  Also I think that other special symbols are also affected. I did not yet check, but I think that for example `__ehdr_start`, `__executable_start`,` __dso_handle`
>  will remain hidden even if be assigned from script.


It looks like we do not have a strict requirement to put `_gp_disp` and `__gnu_local_gp` into the linked file at all. Both these symbols are "magic" symbols. The `_gp_disp` designates offset between start of a function and '_gp' value. I.e. its value used for relocations calculation differs from function to function. The `__gnu_local_gp` can be considered as just a synonym for the `_gp`. GNU ld/gold write both symbols into an output and LLD mimics this behavior, but as far as I know no tool uses these symbols in linked binaries.

Both  `_gp_disp` and `__gnu_local_gp` are undefined symbols in input object files. So if we do nothing, we get the "undefined symbol" error. Do you know any method to suppress this error for particular symbols? We would recognize these special symbols when calculate relocations, but do not define them and do not write them into the output symbol table.


https://reviews.llvm.org/D36579





More information about the llvm-commits mailing list