objcopy does not affect STB_GNU_UNIQUE symbols

[Mark Hills]

Hi Nick, many thanks for the detailed reply. More below.

On Fri, 22 Jul 2016, Nick Clifton wrote:

> > 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 gcc@gcc.gnu.org
> mailing list where you are likely to find such experts.

Of course -- my apologies. I didn't make the connection that, of course, 
C++ details are coming from elsewhere.

I'm also relatively new to this level of detail in C++ and linker 
semantics.
 
> > 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 
> > library.
> 
> 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.

I wasn't, and I'll look at this in due coure; thanks.

> >> 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.

Yes, my assumption too, although perhaps I don't consider the consequences 
to ever be 'bad'. Unlike forcing sharing where it wasn't intended (which 
would be), this won't cause a change in semantics or itself cause a crash.

We already have several processes on the same machine which do not 
'share', and so I don't consider the same happening within a process to be 
really that different.

Processes can even already share resources like memory or file descriptors 
between them, so the developer already has rope to hang themselves if 
they want.

The common example seems to be thread pools and work queues, which you may 
want to share in some scope, or may not.

I think that's why I consider it antisocial if something does have a 
"trump card" to force itself at the process level.

> (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).

I'm probably late to the party here and marvellously uninformed, but 
looking beyond two tiers of "the library" and "the outside world".

It's logical to use a "hierarchy" of static or dynamic linking at multiple 
tiers; libraries composed to form another library, itself used in another, 
then finally perhaps a .so plugin into a host application.

This does mean only two tiers are necessary, as long as we have the 
ability at each linker stage to encapsulate logically. Perhaps this is the 
feature you suggested above, which I'll look into.

> 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.

Thanks for the patch; I would love to give it a try. I am in various 
states of unavailable these next few weeks so it will probably be some 
time before I can.

But I agree that further understanding would be beneficial here.

Many thanks

-- 
Mark