This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Linux vs. libio


>>>>> "Geoff" == Geoff Keating <geoffk@cygnus.com> writes:

Thanks for your email.  You were very clear.

    Geoff> So we have a shared library use graph that looks like this:

    Geoff> netscape --> libstdc++.so.2.8 --> libc.so.6 test -->
    Geoff> libstdc++.so.3 ----^

    Geoff> But this won't work with your proposal.  I can have the
    Geoff> libio in libc.so.6 compiled with the new C++ ABI, in which
    Geoff> case the old libstdc++ won't work, or it can be compiled
    Geoff> with the old ABI in which case the new libstdc++ won't
    Geoff> work.

Right; that's why I was proposing figuring out an *optional* way of
divorcing libio from libstdc++ -- exactly to avoid this problem.  I
understand that's not your long-term goal, but I wanted to support
exactly this situation.  So, I envisioned all of:

  o libstdc++ with old ABI working with old libc.
  o libstdc++ with new ABI working with new libc.
  o libstdc++ with new ABI working with old libc.
  o libstdc++ with old ABI working with new libc.

    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.

In case you missed the earlier discussion, one of the issues is that
things like _IO_XSPUTN don't work because the vtable pointer is now
before the _IO_FILE, not after it.

As was suggested, for example, the vtable pointer issue can probably
be solved by having *two* vtable pointers in the new objects -- the
one the C++ ABI requires, and the one the libio routines expect.  I
think that's the *only* way to solve that particular problem, and I
expect there will be other problems as well.

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.

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

    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.

    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.

One of the things that has happenned up until now is that new features
of C++ have required ABI changes.  The new ABI does explicitly deal
with all the lanague features.  My primary fear is not inadequacies in
the ABI -- it is bugs in the ABI implementation in the compiler.

    Geoff> This is not a new thing.  People with legacy Linux systems
    Geoff> can't use advances in the kernel unless they upgrade their
    Geoff> libc, nor can they run programs that were built under newer
    Geoff> versions of the libc.  In this case, they just won't be
    Geoff> able to use the new ABI until they upgrade, which probably
    Geoff> won't cause them much pain.

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.

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.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]