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

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)) && (keepglobals.size() != 0 && !listcontains(keepglobals, 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) && listcontains(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