Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Jeffrey A Law <law at cygnus dot com>]

  In message <m31z10k1h6.fsf@otr.mynet.cygnus.com>you write:
  > Jeffrey A Law <law@cygnus.com> writes:
  > 
  > > Yes, I'd forgotton about that.  It's one of the issues that needs to
  > > be addressed.  However, I'm not going to say "must never", just that it's
  > > an issues that must be resolved in one way or another.
  > 
  > Every application will be linked against this library and therefore it
  > must be available on the root filesystem where there is certainly no
  > room for gcc.
Not necessarily.  One could certainly argue that if it's on the root
filesystem that it ought to be linked statically.


  > > But we need to -- we're not just building a linux compiler.  We need this
  > > capability across a number of systems to resolve a number of nasty proble
  > ms.
  > 
  > We don't have to care about these things on other platforms (perhaps
  > on BSD but these people do their own stuff anyway).  The problem only
  > exists if the libc is using the code from libgcc and possibly
  > re-exports it.
Yes we do.  hpux, alpha-osf suffer from the same precise problems, only
the problem arises because of symbols that get sucked into libstdc++ and
reexported.

  > > Some native systems have multilibs.  alphas for example, maybe sparcs.
  > > And in the embedded linux world we will likely have systems that need
  > > multilibs.  We can't simply ignore those issues.
  > 
  > None of the systems we care about.
You may not, we do care.  Linux and glibc are just one of many systems we
have to care about in the GCC project.


  > We are completely missing each other.  You completely underestimate
  > the work needed to keep this compatibility library up-to-date.
How do you know that since I've stated nothing about how much effort
it will be to keep that library up to date.

  > Putting this in gcc means you cannot make a new release of gcc until
  > every single platform is handled (means, you have to actually review
  > all the interfaces for each OS/arch combination).
Yes.  And do you think you're telling me something new?

  > If nobody is
  > volunteering you have to do it yourself since otherwise you'll put out
  > a gcc version which can create incompatible binaries or breaks
  > existing one.  This is wrong.
The way to do it is with a binary compatibility testsuite.

  > Doing things outside gcc has the advantage of not delaying the
  > release.  The worst case is that the new release cannot be used on a
  > certain platform but that's it.  And this would be the fault of the
  > people writing the libgcc.so for that arch/OS.
Then do whatever you want *outside of gcc*, as it stands right now I'm
not going to support installing changes in gcc to do this until it's
better thought through.

  > It will also be up to the arch/OS groups to decide when binary
  > compatibility is dropped and all compatibility stuff from libgcc.so
  > should be dropped.
Actually, no.  After gcc-3.0 there aren't supposed to be binary incompatible
changes.  If there are, we will keep the old interfaces, potentially forever.

  > I don't know how to make this clearer, libgcc.so is a system library.
No, libgcc.so is a GCC library.

  > Unless you want to get into the system library development you should
  > not even consider handling the libgcc.so yourself.
I've done system library development and I can see the benefits of providing
these intrinsics in system libraries (and have even done so in a previous
life).  That doesn't mean I believe it's the best way to resolve this problem.

  > Besides, I have not heard a single convincing argument why libgcc.so
  > should be generate as part of gcc.  What do you want to achieve?
And I haven't heard a single convincing argument why it should not be
done in gcc.  What do you want to achive?

I have to think about multiple systems, I'm not going to put blinders on
and just fix linux/glibc problems.  That's not what the GCC project is
about.  

Part of my job is to make sure we do the right thing across the spectrum
of systems we have to support.  That means I have to take a more global
view than you or HJ does.



jeff