You're right, it is a FAQ.  Here's (hopefully) the
definitive answer.

AFAIK, all versions of gcc up through 2.9x.y (I've never
used 3.zz) can generate "in-line" code for adding,
subtracting, and multiplying numerical objects of the long
long data type.  But when it comes to division, they
generate a function call.  The function happens to be one
of the divdi3-family, depending on the exact flavor of data
(signed/unsigned) you're using.  I'd wager a substantial
sum that the __umoddi3 comes from a mod-operation involving
that same data type.

You have several solutions available
    1. Recode to avoid these operations (not always
possible, or even desirable)
    2. Write your own functions to satisfy the compiler's
needs (UGH!)
    3. Link in the entire gcc library with your module.
(It's huge, but it's been done.)
    4. Extract just the modules you need from the library
and link those into your module (That's what I do.  The
only possible drawback is if you do a major update of the
system, you *may* have to re-extract the modules you need
if you still need them.  I emphasize *may* because it's
quite plausible that the generated code and the API for
those operations might not change; also, if a newer
compiler can do the division in-line, it probably won't
hurt to have a few unneeded small library binary files
linked into the module.)

On my RedHat 6.2 system, the library is

/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.90.29/libgcc.a

I extracted the module (using program 'ar') _divdi3.o from
the library and here's the (simplified) link-command from
my Makefile
         ld   -r     -o pc1553.o         ${MY_OBJS}
${MY_LIB}/_divdi3.o

I'd guess that the other module you need called something
like _umoddi3.o but you can check that with ar too.

Norman Dresner
Fellow Avionics Support Systems Engineer & (SGI) Advanced
Signal Processing Laboratory Administrator
Radar Systems Engineering Department
Electronic Systems and Sensors Segment
Northrop Grumman Corporation
Baltimore-Washington International Airport
7323 Aviation Boulevard
Baltimore Maryland 21240

Voice: (410) 993 - 2096 Mornings; all-day voice-mail
 (410) 969 - 8068 Afternoons with answering machine
FAX: (410) 993 - 8084 On-site
 (410) 969 - 8068 Afternoons; call first to arrange
E-Mail: Mornings:
mailto:[EMAIL PROTECTED]
 Afternoons: mailto:[EMAIL PROTECTED]





----- Original Message -----
From: Tim Beamish <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, November 09, 2001 8:59 PM
Subject: [rtl] unresolved symbols and kmalloc problems


> I realize this question may get asked a lot in this forum
but I haven't
> been able to find a post that I understand enough to help
me with my
> problem.
>
> I have a module 'tt_mod.o' that compiles fine but when I
insmod it into
> the kernel it, I get unresolved symbols:
>
> tt_mod.o: unresolved symbol __udivdi3
> tt_mod.o: unresolved symbol __umoddi3
>
> My makefile for making the module looks like:
> ---------------------
> ...
> KLIBS = -L/usr/lib -lm -lc
> LIBGCC = -L$(shell $(CC) -print-libgcc-file-name)
>
> tt_mod.o: tt_mod_temp.o hd_fusion.o ie_io_fusion.o
> $(LD) -r -static tt_mod_temp.o hd_fusion.o
ie_io_fusion.o -o tt_mod.o $(LIBGCC) $(KLIBS)
> chmod ugo+r tt_mod.o
>
> tt_mod_temp.o: tt_mod.c tt_shared.h hd_fusion.o
hd_fusion.h ie_io_fusion.o ie_io_fusion.h
> $(CC) $(KFLAGS) $(KINCLUDE) -c tt_mod.c -o tt_mod_temp.o
> chmod ugo+r tt_mod_temp.o
>
> hd_fusion.o: hd_fusion.c hd_fusion.h ie_io_fusion.o
ie_io_fusion.h utility_fusion.h hapdev_fusion.h
> $(CC) $(KFLAGS) $(INCLUDE) -c hd_fusion.c -o hd_fusion.o
>
> ie_io_fusion.o: ie_io_fusion.c ie_io_fusion.h
> $(CC) $(KFLAGS) $(INCLUDE) -c ie_io_fusion.c -o
ie_io_fusion.o
> ...
> --------------------
> I've found that the problem has something to do with
hd_fusion.o. If I
> remove it from the project, everything is fine.
>
> From reading former posts, I understand that these
unresolved symbols are
> often caused by using math functions that we're not
supposed to use in the
> kernel. hd_fusion.o only does a few cases of division and
in each case,
> it's with floats. Is that not allowed? I've tried to use
the extra linking
> flags when making hd_fusion.o and I get these comments
(but it still makes
> it):
>
> gcc: -lm: linker input file unused since linking not done
> gcc: -lc: linker input file unused since linking not done
>
> Also, as a seperate problem, when I compile hd_fusion.c I
get a warning
> that an implicit declaration of function `kmalloc'
exists. Are we allowed
> to use malloc in the kernel? I'd rather because kmalloc
is defined in
> rlt_cpp.h and when I include that file, it redefines a
whole bunch of
> stuff (like NULL) and nothing is happy. What is rtl_cpp.h
used for anyway?
> It's name implies that it has something to do with C++
functions for rtl
> but I'm writing everything in C.
>
> Finally, where is the best documentation on the header
files located in
> the /include directory for rtlinux?
>
> Thanks in advance,
> Tim
>
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail
[EMAIL PROTECTED]
> --
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/
>
>

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/

Reply via email to