Symbol versions for inlined symbols

Symbol versions for inlined symbols

[Mike Hearn]

Hi,

One problem with the parallel C++ ABI versioning (which makes it not so
useful) is that symbols in the libstdc++ namespaces are put into the
generated binary if you use the STL. Those generated symbols are *not*
symbol versioned so conflicts can still occur.

This is registered in bugzilla and has been for a while, with no sign of a
fix. So I thought I'd look at it.

Would an acceptable solution be to have a new attribute that set the
symbol version for inlined functions. That way, the STL headers could be
annotated like so:

class XXX
{
	int STD_VERSION std::whatever() { return 4; }
}

An alternative approach would be to have the linker assigned inlined
symbols the same version tag as whatever the same symbol in libstdc++ has,
but I'm not sure how I'd implement this.

Does anybody have insight?

thanks -mike

Re: Symbol versions for inlined symbols

[Daniel Jacobowitz]

On Sat, Jul 30, 2005 at 09:33:45PM +0100, Mike Hearn wrote:
> Hi,
> 
> One problem with the parallel C++ ABI versioning (which makes it not so
> useful) is that symbols in the libstdc++ namespaces are put into the
> generated binary if you use the STL. Those generated symbols are *not*
> symbol versioned so conflicts can still occur.

You may wish to read the proceedings from this year's GCC summit, where
another solution was presented by some gentlemen from Intel.  For
various reasons, symbol versioning is not a useful solution to this
problem.

No one objected to their solution in principle, AFAICT, although there
was some discussion afterwards about whether the use of strong
namespace using was really necessary.  I'm afraid I don't understand
C++ well enough to explain the rest of that conversation.

May just need someone to do the work.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Symbol versions for inlined symbols

[Mike Hearn]

On Sun, 31 Jul 2005 00:57:49 -0400, Daniel Jacobowitz wrote:
> You may wish to read the proceedings from this year's GCC summit, where
> another solution was presented by some gentlemen from Intel.  For various
> reasons, symbol versioning is not a useful solution to this problem.

I hadn't seen that, thanks. It's an interesting approach but a bit
confusing to somebody like me who doesn't use C++ very often: it sounded
from their writeup like you'd have to modify application code, and then in
other parts it sounded like actually only the libstdc++ headers would need
to be modified and apps would do the right thing transparently.

From my perspective the most convenient solution would be a way to modify
ELF symbol scoping (which is what symbol versioning does, in a complicated
sort of way). Instead of starting lookup for a symbol in libC from app,
going on through libstdc++.so.5, libA, libB, libC, libstdc++.so.6, libD:

app
 libstdc++.so.5
 libA,
 libB,
 libC,
   libstdc++.so.6
   libD

something more similar to Windows where a symbol lookup starting in libC
checks libC, libstdc++.so.6, libD, app, libstdc++,so.5, libA, libB would
work.

That way, the GLOBAL WEAK symbols in the std namespace would always
resolve to what you'd intuitively expect: the dependencies of that object.
ELF compatibility would mostly be preserved as symbols could still be
resolved to the parent and other objects in the image, but the chance of
cross-wiring would be reduced.

I think this is what the DT_1_GROUP flag is supposed to do, but for some
reason it was never implemented in the glibc linker. Does anybody know why?

Last time I talked about this with Michael Meeks at Novell, he seemed to
think the semantics of the DT_1_GROUP flag would mess up C++
exception handling, which relies on the current ordering. Is that so?

Oh, final thing - the GCC summit paper made it sound like only
rare proprietary apps need the ability to mix multiple libstdc++ versions
in the same image, but it's a very common thing to do for open source
programs too: specifically, games. Games are why I'm asking, actually :)

We already have nasty workarounds for this issue in place for NetPanzer,
Lincity and a few other projects that distribute binaries and may be
linked against other C++ libraries already on the system. The classic
example is "C++ Game -> SDL -> SDL_audio -> libArts (for KDE audio) ->
mismatched libstdc++ version -> crash in std::string".

thanks -mike

Re: Symbol versions for inlined symbols

[Daniel Jacobowitz]

On Sun, Jul 31, 2005 at 03:53:42PM +0100, Mike Hearn wrote:
> On Sun, 31 Jul 2005 00:57:49 -0400, Daniel Jacobowitz wrote:
> > You may wish to read the proceedings from this year's GCC summit, where
> > another solution was presented by some gentlemen from Intel.  For various
> > reasons, symbol versioning is not a useful solution to this problem.
> 
> I hadn't seen that, thanks. It's an interesting approach but a bit
> confusing to somebody like me who doesn't use C++ very often: it sounded
> from their writeup like you'd have to modify application code, and then in
> other parts it sounded like actually only the libstdc++ headers would need
> to be modified and apps would do the right thing transparently.

The latter is the whole point.

> From my perspective the most convenient solution would be a way to modify
> ELF symbol scoping (which is what symbol versioning does, in a complicated
> sort of way). Instead of starting lookup for a symbol in libC from app,
> going on through libstdc++.so.5, libA, libB, libC, libstdc++.so.6, libD:
> 
> app
>  libstdc++.so.5
>  libA,
>  libB,
>  libC,
>    libstdc++.so.6
>    libD

You've completely missed the problem here, I'm afraid.  You can't use
anything like symbol scoping to do this, because the generated symbols
will end up in the application and in libC.  Besides, what if libC ends
up being a static library using libstdc++.so.5 and you want to rebuild
app?

Solving this little bit of the problem just isn't worth it.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Symbol versions for inlined symbols

[dank]

> You may wish to read the proceedings from this year's GCC summit, where
> another solution was presented by some gentlemen from Intel.  For
> various reasons, symbol versioning is not a useful solution to this
> problem.
>
> No one objected to their solution in principle, AFAICT, although there
> was some discussion afterwards about whether the use of strong
> namespace using was really necessary

FWIW, I tried to capture some of the discussion at
http://kegel.com/gcc/diary.txt