This is the mail archive of the
mailing list for the binutils project.
Re: objcopy does not affect STB_GNU_UNIQUE symbols
> I can see the developer of the C++ library has made their intent clear,
> but should it not really be in the hands of user of the library to have
> final say in the 'scope' of these? This boundary of the process is
> somewhat artificial; there may be other boundaries.
OK - first off, let me state that I am not a C++ expert by any means,
and that I would *strongly* recommend that you take this up on the firstname.lastname@example.org
mailing list where you are likely to find such experts.
> The software is implemented in C++ but exports only a simple "C" API. The
> only global symbols are those we expressly make visible after linking the
As an aside, are are you aware of the new "import library" generation feature
now supported by the linker. I am not sure if it exactly matches your
requirements, but it might be worth investigating.
>> If you convert a unique symbol into a local symbol you will destroy this
>> requirement, and basically, your C++ code will stop working.
> Can you be more specific?
Not really - I was trying to anticipate what real C++ library experts would
say. My assumption is that unique symbols really do need to be unique or
else something will go wrong. Precisely what though, I do not know.
My guess would be that if your library contains two instances of the same,
unique, symbol then by converting them into local symbols you will end up
with two separate symbols at run-time, instead of just one. Depending upon
how the code is written, this could be serious. If your code assumes that
a static variable really is static and shared amongst all instances of a
particular class, then having it suddenly become one-copy-per-instance
could be a very bad thing.
(It seems to me that what is needed is a way to say that symbol X is unique
to library FOO, but also hidden to the outside world. So basically a symbol
with STB_GNU_UNIQUE binding and STV_HIDDEN visibility. I wonder if that would
work... You might even be able to achieve this by adding an attribute to the
C++ source code that is responsible for the creation of the unique symbol).
That said, maybe you would like to try some investigation yourself ? Attached
is a small patch to the objcopy program that *might* allow --localize-symbol
to work on unique symbols as well. (I say "might" because I have not actually
tested this patch). Assuming it works, you can then test your library to see
what, if anything, is broken by the change.
I am not currently willing to apply this patch to the official sources. Not
without confirmation from a real C++ expert that this would be OK, and
confirmation from you that it works. But at least it is something worth trying.
diff --git a/binutils/objcopy.c b/binutils/objcopy.c
index 2e8ff27..a334cf6 100644
@@ -1486,7 +1486,7 @@ filter_symbols (bfd *abfd, bfd *obfd, asymbol **osyms,
used_in_reloc = TRUE;
else if (relocatable /* Relocatable file. */
- && ((flags & (BSF_GLOBAL | BSF_WEAK)) != 0
+ && ((flags & (BSF_GLOBAL | BSF_WEAK | BSF_GNU_UNIQUE)) != 0
|| bfd_is_com_section (bfd_get_section (sym))))
keep = TRUE;
else if (bfd_decode_symclass (sym) == 'I')
@@ -1550,13 +1550,13 @@ filter_symbols (bfd *abfd, bfd *obfd, asymbol **osyms,
- && (flags & (BSF_GLOBAL | BSF_WEAK))
+ && (flags & (BSF_GLOBAL | BSF_WEAK | BSF_GNU_UNIQUE))
&& (is_specified_symbol (name, localize_specific_htab)
|| (htab_elements (keepglobal_specific_htab) != 0
&& ! is_specified_symbol (name, keepglobal_specific_htab))
|| (localize_hidden && is_hidden_symbol (sym))))
- sym->flags &= ~ (BSF_GLOBAL | BSF_WEAK);
+ sym->flags &= ~ (BSF_GLOBAL | BSF_WEAK | BSF_GNU_UNIQUE);
sym->flags |= BSF_LOCAL;