Re: Linux vs. libio

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:

    >> The problem is that part of the libio API is the C++ vtables,
    >> so any ABI change that modifies the layout of the vtable (such
    >> as -fvtable-thunks) or how the vtable is found breaks libio.

    Jeffrey> Right.  This is precisely why I stated that we should not
    Jeffrey> change libio without changing glibc too.  They need to
    Jeffrey> change in lock-step.

We're not talking about a release here.  We're just talking bout
development.

It isn't really required that libio and glibc change in lockstep.  It
certainly doesn't matter on platforms that don't use glibc.

What's required is that if libio changes on IA32 Linux (which, under
my proposal, it would only do when compiled with -fnew-abi), then it
needs to be simultaneously disentangled from glibc, and work in the
way that libio works with other C libraries.  If that disentanglement
can't be done, then it can't be done -- people will only be able to
use -fnew-abi on non IA32 Linux platforms.

If we decide to *release* an IA32 Linux compiler where -fnew-abi is a
supported option (which we have not yet done to date), then we
probably want to do so only when there's a C library that has the new
libio.  That's not a requirement for releasing an IRIX compiler where
-fnew-abi is a supported option.

It's very hard to move in lock-step; I think there are IA32 Linux
users who would like to try out -fnew-abi (to see if it works, to see
if it performs better, etc.), but who don't want to upgrade their C
libraries.  (I'm one of those users.)  

Why should we make it hard for people to test the new ABI?

There are really only a few options that I can think of:

  1. Don't implement -fnew-abi.

  2. Implement -fnew-abi, but ignore the fact that libio is broken
     for the new ABI.  

     This solution makes -fnew-abi difficult to test, and makes
     an -fnew-abi compiler useless to the community, unless they 
     get iostreams from somewhere else.  (For example, SGI has
     a conforming implementation available at
     http://www.sgi.com/Technology/STL.)

  3. Implement the libio changes in the glibc version.  That will 
     make it considerably more difficult to test the work we are
     really trying to do: implement the new ABI.  Just mucking with
     the build process in GCC to make this work will be a
     nuisance.  Then, we have to either wait until the libio in glibc
     is considered stable and move the result back into the compiler,
     or backport the changes to the version in the compiler.

  4. Implement the libio changes in the compiler version.  That
     makes testing easy, and doesn't risk changing the libio to 
     a newer, less stable version.  Then, forward-port the changes
     from there into glibc.

Option 4 makes sense.  It requires minimal changes.  It allows us to
implement and experiment with -fnew-abi most effectively.  Once things
are working smoothly, we can move the changes into glibc.  We'll
commit to helping with that process.

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