Re: Plans for ABI migration

[Bernardo Innocenti <bernie at codewiz dot org>]

On Wednesday 10 January 2001 02:13, Gerald Pfeifer wrote:

 > On Wed, 10 Jan 2001, Bernardo Innocenti wrote:
 > > Yes, I was thinking that the gcc developers could get in contact
 > > with the glibc guys to discuss a coordinated effort to let ld.so
 > > recognize ELF modules compiled by the new compiler.

 > You are aware that GCC runs of dozens of platforms that do not use
 > glibc (several of which are also free software)?

 Of course I do. I'm also an official NetBSD developer. But since
most BSD derivations have full control over their userland, they
don't need to get in contact with anybody to sort out this problem.

 For instance, when the NetBSD guys will decide to upgrade the
whole system to gcc 3.x (not before 2002 I guess), they'll first
fix all the source base so that it compiles nicely with -Wall and
-Werror, then take whatever measures they need to ensure enough
backwards compatibility for the ABI (which probably means none).


 > >   - gas preserves it into the ELF object module
 >
 > And dozens of platforms which do not use gas, either because it is not
 > available there by default or because it just has not been ported/does
 > not work properly there?

 Yes, a few don't even use ELF, for what matters. There are certainly
many ways to encode tips for the dynamic linker in an object file. If
everything else fails, using a ".asciz" would be the last choice that
works for anybody. I'm not an expert of fancy assembly directives and
object formats, but there's surely a way to do it.


 > > Even if I'm used to compile stuff from source code, I always
 > > disliked the UNIX notorious lack of binary compatibility between
 > > kernel versions (BSD) or library versions (Linux). There's certainly
 > > room for improvement.

 > While there *is* room for improvement, you would be surprised by the
 > level of compatibility that Sun, for example, has been offering with
 > SunOS and Solaris. Also modern decendants of BSD like FreeBSD offer
 > excellent backwards compatibility (I just tried and ran an old a.out
 > binary, orginally generated for FreeBSD 2.x on a FreeBSD 4.2 system).

 I also happen to use a Sun at home, and I was quite happy with its
level of binary compatibility (except when AnswerBook 1 stopped working
when I upgraded to Solaris 2.8, but that's another story ;-)

 I gather FreeBSD does not rely any more on the /dev/kcore insanity
to let userland programs such as ps snoop into kernel structures
to gather information :-)

 NetBSD "solved" the problem by moving all code that messes into
kcore into a shared library, but never managed to fix it the way
Solaris and Linux did.


 > But, what I actually mean to say is: While GNU/Linux is very important
 > to the GNU project and GCC should support it as well as possible,
 > there are lots of other (free) systems out there which we have to
 > consider.

 Each OS has to address this problem separately. On OSes where gcc
is not the native compiler, it would be even better (or mandatory)
to support the C++ ABI published by the OS vendor instead of gcc's
own one.

 In the mean while, doing something for the benefit GNU/Linux only
would be a Good Thing(tm).


 > And I don't think there's a solution with a good cost:gain ratio in
 > general even for GNU/Linux platforms. Breaking the C++ ABI has been
 > happening for every major release of GCC in the past, and in fact we
 > hope that this will be the last time for a long time that we'll have
 > to do so, due to the new C++ ABI.

 It's quite difficult to maintain perfect C++ compatibility for
shared libraries. Even if gcc never changes mangling and vtables
structure again, even a small improvement or bug fix made to
libstdc++ is likely to break something. Changing a single
parameter type to a single template could lead to link conflicts
when a 3rd party library compiled with one version of libstdc++
exposes something to programs compiled with another version.

 There's little you can do about it except adding some smarness
into ld.so to choose the right libraries.

-- 
  // Bernardo Innocenti
\X/  http://www.codewiz.org