[llvm-dev] GNU objcopy compatibility for --globalize-symbol and --keep-global-symbol (-G)

Eric Christopher via llvm-dev llvm-dev at lists.llvm.org
Tue Sep 4 16:32:51 PDT 2018


Hi Jordan,

No objections per se, however:

However, the actual thing GNU sources for objcopy.c does (simplified to
> just relevant bits) is this:
>
>   for (auto sym : symbols) {
>     auto flags = sym->flags;
>     auto name = sym->name;
>
>     // If flag is global/weak, and --keep-global-symbol includes it,
>     // make it local
>     if ((flags & (GLOBAL | WEAK)) &&
>         (keep_globals.size() != 0 && !list_contains(keep_globals, name))) {
>       sym->flags &= ~(GLOBAL | WEAK);
>       sym->flags |= LOCAL;
>     }
>
>     // If flag is local and --globalize-symbol is set, make it global
>     // Note: checks flags, not sym->flags
>     if ((flags & LOCAL) && list_contains(globalize, name)) {
>       sym->flags &= ~LOCAL;
>       sym->flags |= GLOBAL;
>     }
>   }
>
> This seems strange for a few reasons:
>
> * Weak symbols are not globalized. The help for --globalize-symbol never
> mention it doesn't handle weak symbols, so this seems like a bug in GNU
> objcopy.
>
> * If one were to do "--globalize-symbol SomeGlobal --keep-global-symbol
> SomeOtherGlobal", you might expect that both SomeGlobal and SomeOtherGlobal
> are global in the output file... but it isn't. (Admittedly, this is a weird
> command line usage). Because --keep-global-symbol is set and doesn't
> include SomeGlobal, SomeGlobal will be demoted to a local symbol. And
> because the check to see if we should apply the --globalize-symbol flag
> checks "flags" (the original flag set), and not "sym->flags", it decides
> not to do anything, so SomeGlobal remains a local symbol.
>
>
I'd probably send a message to the binutils list with this (happy to be
cc'd on it) with "hey, this behavior and the documentation doesn't match.
Do we know of anything that depends on this behavior?"

Or something like that and see who responds and what they say. :)

Thoughts?

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180904/e831f129/attachment.html>


More information about the llvm-dev mailing list