This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: objcopy behavior for --globalize-symbol and --keep-global-symbol (-G)
- From: Nick Clifton <nickc at redhat dot com>
- To: Jordan Rupprecht <rupprecht at google dot com>, binutils at sourceware dot org
- Cc: Eric Christopher <echristo at gmail dot com>
- Date: Mon, 17 Sep 2018 15:56:24 +0100
- Subject: Re: objcopy behavior for --globalize-symbol and --keep-global-symbol (-G)
- References: <CABC7LbRk6KFPO_XBfnZ6V7QrHQsQPJ=DKWqbVziWrEy7C3KYiQ@mail.gmail.com> <CABC7LbRxa9UPnLuh3OSXcax45eCoFLoPZfHZk5LTguS_tkc40Q@mail.gmail.com>
Hi Jordan,
> As part of work on LLVM binutils, I've been spending time looking at
> GNU objcopy. One thing I'm confused by is how --globalize-symbol and
> --keep-global-symbol are supposed to work, especially when comparing
> their documented effects vs reading the code.
To be fair, this code was never planned out fully, rather it grew organically...
> * Weak symbols are not globalized. --help/man pages never mention
> this. Is this intentional?
Yes. There is no such thing as a weak local symbol. (Well there shouldn't
be anyway). So when promoting from LOCAL to GLOBAL there is no need to also
check for WEAK.
> * Supposing we had an object file with two globals, SomeGlobal and
> SomeOtherGlobal, 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. 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.
All true.
> Although this is
> a weird edge case, should this be changed so that --keep-global-symbol
> implicitly keeps anything also specified via --globalize-symbol? (The
> code seems technically correct with respect to the documentation, but
> IMO the behavior is counter-intuitive).
Actually I think that it should be an error to mix the two options.
However you code it, somebody is going to get confused about the behaviour
when both options are specified. Best to keep things simple and consider
the two options to be mutually exclusive.
Cheers
Nick