I've already brought up the issue with gcc "millicode" here, more
details are in toolchain/22452.  Attached are the changes from my tree
that let me build a working dynamic world for hpcsh (less than 4k
compressed, so I figure I can just attach it directly).

Summary:

* the problem with "millicode" vs. dynamic linking is that millicode
  cannot be called via .plt (i.e. across .so boundaries)

* all functions that gcc has in lib1funcs.asm and that we provide in
  libc are moved to a new library, that I called "gcc0" (for want of a
  better name)

* libgcc0.a and libgcc0_pic.a are built out of those sources (each
  library is 720 bytes of text), all entries in the -lgcc0_pic are
  marked .hidden

* all .so's are linked with -lgcc0_pic to get their own private copies
  of the millicode

* all programs are linked with -lgcc0 (in addition to -lgcc)

The net effect is that the millicode is always called directly, thus
preserving gcc expectations of which registers are clobbered by calls 
to the millicode.

Linux/SH gcc maintainer told me that for Linux he solved this problem
by keeping the millicode functions in libgcc (marked .hidden in
libgcc_pic.a) and always linking .so's against -lgcc_pic.  But this is
the wrong solution, as it pulls in too much of libgcc into each shared
object, exception handling code in particular - with disastrous
results (Nick Hudson has fixed this in our tree already).

One outstanding problem with those changes is that our implementation
of udivsi signals SIGFPE for division by zero and so needs raise(3)
from libc.

To switch sh3 ports to gcc3 we need something like the attached patch
committed.  I gather sh5 and hppa have similar issues with millicode
(we even have a hack for hppa millicode in our .mk files already).

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