>However, we didn't build this for known history in libgcc, so there is a
>binary compatibility issue. 

we didnt build it as libgcc or libgcc2 due to an misunderstanding)
(that's what jtc finally said.)

>If you want to propose yanking those that were not there dating all
>the way back through a port's shlib implementation date, then go
>right ahead.  :)

My take is that if our GCC ever emits a call to a libgcc2 routine
which the native FSF/EGCS build never called, then that's an egregious
bug in gcc:), and one where busting the application is probably a
/good/ thing :).

More seriously, it'll lose in /very/ ugly ways if egcs ever starts
using nonstandard calling sequences for libgcc2 routines.  Darn things
should never have been in libgcc2 in the first place.  Maybe we can
fix that by dynamically linking a shared libc against libgcc2, but I
wasn't proposing going that far just yet.

.Huh?  If that's true, then libkern should probably be changed to a .a, not a
>.o.  (Why it's a .o I'm not quite sure anyway.)

LKMs. Cant tell in advance what one might call. But for any given
GCC/egcs version and arch, the libgcc2 calls which gcc _acutally_ uses
(as configured by FSF/Cygnus) is a small subset of what we currently
compile into libkern (which is everything, irrespective of what the md
open-codes).

Last time I tried this (which was yers ago) only the insn routines
from libgcc2 that werent already in the .md got compiled into libgcc2.
I've kicked off a Cygnus-style configure of our gcc; i'll let you know
what it ends up building.

>: Plus, its simply not right, and we try and do the right thing. :)
>
>Understandable....

Sure.  Nothing stronger implied.