Re: Linux vs. libio

[Geoff Keating <geoffk at cygnus dot com>]

> From: Mark Mitchell <mark@codesourcery.com>
> Date: Mon, 20 Dec 1999 18:06:29 -0800

>     Geoff> So we need a libio in glibc which will work for _both_ the
>     Geoff> old ABI and the new ABI.
> 
> If we can do this, that will be wonderful.  I'm in no way opposed to
> this, if it is technically feasible.  I'll try to see how this might
> be done.
...
> But, one of the vtables will contain thunks that adjust the this
> pointer before calling through the real vtable.  So there will be two
> costs to just this level of compatibility: extra space, and extra
> time.  That seems undesirable to me.

It's not like there is a _choice_.  We must maintain backwards
compatibility.  If this costs in space/time, then that's unfortunate
but we have to live with it (and try to minimize it, of course).

If we did have to do this, we could at least try to make the runtime
cost apply only to old applications.  That way, it will diminish over
time.

> Can you suggest a way of making this work that doesn't involve a
> performance hit?

Another way to make it work is to have glibc detect the version of gcc
in use and have the new libio be the default when the new gcc is being
used, through the use of symbol versioning---that is, have two
completely separate copies of libio inside glibc "like multilibs, but
at runtime" (now _there's_ a slogan that inspires confidence :-) ).
Possibly something could be done to make this work without recompiling
glibc.  You couldn't mix C++ shared objects compiled with both
compilers, but I don't think this is a serious problem.

One advantage of this is that we could make the new-ABI code more
efficient, as it would avoid some of the backwards compatibility
baggage we have now.

>     Geoff> more complicated if you only want one library.  Hopefully
>     Geoff> the new C++ symbol mangling and the old one don't overlap
>     Geoff> so the 'more complicated' just means specifying both
>     Geoff> versions of the object files on the link line.
> 
> The mangling has not yet been decided, so that's unclear.  But note
> that, in your proposal, even the C parts of libio need to handle both
> ABIs, so I don't think mangling is enough to keep things totally
> separate.

I'm not sure that libio needs to handle both ABIs _in the same
process_.  Just inside the same libc.so.

>     Geoff> libio is special because it is part of glibc.  The C++ ABI
>     Geoff> changes at pretty frequent intervals, the C ABI doesn't.
> 
> It is the intention of myself (and I believe Jason Merrill would
> agree, after the new ABI is implemented, never to change it again --
> just as you folks have committed to with libc.  We recognize that one
> of the obstacles to widespread C++ acceptance has been the lack of a
> stable ABI, and I'm hoping that the new ABI, which has been developed
> by a committee of intelligent people, will be good enough that we can
> stick with it indefinitely.  Time will tell, of course.

Oh good!  I would very much support this.

> One of my concerns is testing: I want people to be able to test the
> new ABI.  Lots of those potential testers are on IA32 Linux, but they
> don't really want to upgrade their systems, or even have to install
> new versions of libc in funny hidden places just to do the testing.

For testing purposes, you can just say "check libio out from this
branch" and put whatever hacks you like in it; that's no problem.
But before the release we do need to solve the whole problem.

> But I think you and I will have to agree to disagree on this point; I
> think we just evaluate the likelihood of people being willing to
> upgrade differently.



-- 
- Geoffrey Keating <geoffk@cygnus.com>