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

[Jason R Thorpe <thorpej at zembu dot com>]

On Thu, Jul 13, 2000 at 06:35:37PM -0300, Alexandre Oliva wrote:

 > But there's a major problem too.  What if I decide to upgrade one of
 > GCC or glibc.  What now?  New programs I create will depend on the
 > most recent libgcc and glibc, but one of the libraries (the one that
 > was not updated) will depend on the older version of the other.  So,
 > if I had upgraded GCC, I'd have two different, potentially
 > incompatible versions, of libgcc loaded into the same process.  I'm
 > afraid this may not work.

This seems like a classic example of:

Patient: "It hurts when I do this."
Doctor: "Well, then don't do that."

I.e. the obvious solution is to not install libgcc as a shared
library.  I know this is how the BSDs do things, and it seems to
work well through both libc and compiler upgrades.

You could also use symbol renaming to keep backwards-compatible
versions of the functions in the new library.  This is what NetBSD
does to avoid having to bump its libc major number[*] when various
bits of the libc/syscall ABI change for one reason or another.

For example, when NetBSD changed the layout of the `stat' structure:

#ifdef __LIBC12_SOURCE__
int     stat __P((const char *, struct stat12 *));
int     fstat __P((int, struct stat12 *));
int     __stat13 __P((const char *, struct stat *));
int     __fstat13 __P((int, struct stat *));
#else
int     stat __P((const char *, struct stat *)) __RENAME(__stat13);  
int     fstat __P((int, struct stat *))         __RENAME(__fstat13);
#endif

...where `12' and `13' refer to the major versions of those functions.
In the event that the libc major is bumped to 13 some day, the old
functions go away, and the renamed functions get moved into their
rightful place in the namespace.

FWIW, those __RENAME() examples above expand into:

	__asm__("__stat13")
	__asm__("__fstat13")

As long as the prototypes are in-scope, you get the correct versions
of the functions.  In the event that the prototypes are not in-scope
(e.g. some lazy 3rd party package), there are linker stubs that produce
warnings when the program is linked indicating that the incorrect
versions of the functions were used, and that the program should be
modified to bring prototypes into scope.

[*] Bumping libc major is a serious pain.  When you do, you basically
need to bump the major number of all other shared libraries, as well,
since they use libc symbols.  This is not unlike the problem with
shared libgcc/libc you are talking about.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>