Re: unresolved symbol __udivsi3_i4

[Jan-Benedict Glaw]

On Fri, 2004-09-24 13:15:26 +0200, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
wrote in message <Pine.GSO.4.61.0409241314530.27692@xxxxxxxxxxxxxxxxxxxx>:
> On Fri, 24 Sep 2004, Jan-Benedict Glaw wrote:
> > > > > unresolved symbol __udivsi3_i4
> > > > # objdump -T /lib/libgcc_s.so.1|grep div
> > > > 000024c0 g    DF .text  00000162  GLIBC_2.0   __divdi3
> > > > 00002b80 g    DF .text  000001ed  GCC_3.0     __udivmoddi4
> > > > 00002870 g    DF .text  00000120  GLIBC_2.0   __udivdi3
> > > > 
> > > > you can link module with libgcc.a or fix it.
> > > 
> > > Just add an implementation for __udivsi3_i4 to arch/sh/lib/. They already have
> > > udivdi3.c over there.
> > 
> > Either that (which I don't like!), or have a try compiling the kernel
> 
> Why don't you like that? It's done that way on most architectures.

Well, the kernel is (or should be) a freestanding program, so it
shouldn't use *any* external code (and it doesn't, intentionally).
We're working hard not linking in libgcc.a (IIRC some archs actually do
that) (because eg. your compiler was compiled for i686-pc-linux-gnu, you
want to compile for a real i386 and end up with Pentium-alike code in
your i386 kernel).

So people started doing freestanding implementations of eg. __udivsi3 in
their kernel files. But why should they? GCC also could have emitted
inlined code to do that task, without ever calling an external function
for that.

However, this topic has been discussed several times with no real
resolution, so I guess we won't find a real cool solution this time,
too.

MfG, JBG (and greetings from Oldenburg!)

-- 
Jan-Benedict Glaw       jbglaw@xxxxxxxxxx    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

Attachment: signature.asc
Description: Digital signature