toolchain/22452 is the main showstopper for switching sh3 ports to
gcc3.  I've already wrote about this problem, but let me sum it up
again.  Cc'ed to port sh5 port meister, as I think it might have the
same problem.

The problem is exposed by shared libraries now that gcc3 can generate
PIC code for SuperH.

Some of the assembly language libgcc functions (from lib1funcs.asm)
are treated specially by gcc, as a sort of millicode with a different
calling convention.  E.g. "udivsi3_i1" instruction emits a jsr to
__udivsi3, but this is not a normal function call, as gcc thinks that
it will only clobber r4, so gcc will happily store live values in
scratch registers across a call to __udivsi3.  This is ok for
statically linked __udivsi3, as this assembler function really doesn't
clobber anything else.  However this is no longer ok if we need to
call __udivsi3 via PLT (e.g. into or out-of a shared library).

To solve this problem we need a static library with PIC code for all
such functions, marked as ".hidden", we then need to link all shared
libraries against this millicode library so that all each shared
library gets its own private __udivsi3 &c that it can call directly.
We also need a copy of __udivsi3 &c in libgcc.a.

AFAIK, linux-sh folks solved this by simply linking all shared libs
against libgcc_pic.a (that has relevant symbols marked as .hidden).
I'm not sure if this is ok, as it will mean that each shared lib will
pull in *all* the symbols it needs from libgcc.  OTOH, this approach
avoids the need for introducing that special libgcc_millicode_pic.a
(or whatever we would call it).

Another issue here is that in our tree we ignore "lib1funcs.asm"
supplied by gcc and provide our own replacements in libc.  So we will
need to link our code (currently in lib/libc/arch/sh3) into libgcc,
which will probably require changes to the way libgcc reachover
makefiles are generated.  In any case, the offending functions need to
be dropped from libc.

toolchain/22452 (this problem) and toolchain/22489 are the only two
problems that prevent sh3 ports from switching to gcc3 (and get shlibs
support funally), so any help is greatly appreciated.


SY, Uwe
-- 
uwe@ptc.spbu.ru                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen