On Sun, 25 Oct 1998, Richard Earnshaw wrote:

: Not quite.  We could also fix the problem by bumping the major version of 
: shared libs that changed their interface.  Old programs (built with the 
: old compiler) would then continue to use the old libs (built with the old 
: compiler).  New programs and libs could then be set up to do things 
: differently.

Um, we can't do that with, say, any library in the NetBSD source tree,
particularly libc and libm.  And what about third-party code?

: Don't forget the ABI was also changed between 1.2 and 1.3 when we went 
: from hard to soft floating point.  The only reason we got away with it 
: then was that 1.2 didn't have shared libs.

Well, now we do.  Shared libraries bring in their own very large can of
worms.

: > At worst, if stack-return of structs
: > uses a different pointer register than the two regs used for reg-return, we
: > need to have egcs provide both interfaces simultaneously unless one of the
: > -f*-return options is given.
: 
: I don't follow.

Some platforms return the pointer to a stack-returned value in a certain
register, that may or may not be the same regster as a value-return
register.  Some platforms don't return the pointer to a stack-returned value
at all (the compiler can handle it).  I don't know which one ARM is.

If there's a way to have functions return in *both* registers and stack,
that would be ideal as the default compile mode, such that libc could be
used with code assuming either stack or register return.  (AFAIK, i386 does
precisely this:  both return types simultaneously by default.)

: The only way really is to put the old code back in, maybe with a flag to 
: allow switching between the two; but I'm still of the opinion that this 
: would be a bad idea (see my reply to the other Todd).

Binary compatibility is one of NetBSD's primary goals, and what you are
proposing breaks that in two.  We can't just go change an ABI once it has
been in a released, working product.

Charles Hannum started work on fixing up the relocs in shared libraries on
ARM, and that is a similar type of break from the past, but it _can_
have binary compatibility added in (and users are likely to demand such
compatibility once fixes for PIC are made).

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)