Subject: Re: Kernel Building Update.
From: Brian Waite (bwaite@cspi.com)
Date: Thu Oct 04 2001 - 09:15:36 MDT
Unresolved symbols are not quite like a forgotten #include. A forgotten
#include will throw a compilier error when you can't find defines or
prototypes. Un esolved symbols are more like forgetting a -l<libname> in an
appilcation. When you do this the compiler will complian on the final linking
step and throw an error. The final step of linking makes sure that there are
no unresolved symbols. Think of a large application I build 10 .o files and
then I link them together to make one complete application. A kernel module
does not fully resolve all the symbols. What happens is that the kernel
functions (printk,....) are already linked into the kernel, to save space
kernel modules reference these as oppossed to making a copy of printk in your
kernel module. The last linking step then is done when the module is loaded
into the kernel. That is why the unresolved symbols appear at load time. When
you compile in link your module during link time you tell the linker, "I will
link all unresolved symbols later", The compilier then ignores unresolved
symbols. It is up to the kernel to have all the unresolved symbols loaded
either in the kernel proper or in modules that are loaded prior to loading
the current module.
Just for fun try the following:
nm <module_name> | grep " U "
This will list all the unresolved symbols in the module. You could now grep
for each of these on /proc/ksyms and see if all the symbols exist. It is a
waste of time but it is interesting sometimes.
On Thursday 04 October 2001 10:28 am, you wrote:
> --On Wednesday, October 3, 2001 12:44 AM -0700 "Timothy A. Seufert"
>
> <tas@mindspring.com> wrote:
> > At 11:11 PM -0500 10/2/01, Kitt Thompson wrote:
> >> Hey Tim, thanks for the info on the updated Modutils. I nabbed
> >> them from the YDL site and installed them as per your instructions.
> >> But, it didn't fix the problem. I get the same messages upon boot
> >> time. I ran depmod -a while under the new kernel and it gave me
> >> a whole bunch of Unresolved symbol messages. Almost as if none of
> >> the modules loaded.
> >
> > Did you rebuild the kernel and modules? You'll have to do a make clean
> > followed by make and make modules at least.
>
> Yes, I did. But I didn't change the EXTRAVERSION variable which might make
> a
> difference based on Gavin's information (see Gavin Hemphill's email
> dated 10/3/2001.) I'm building a new kernel as I typoe this. I'll let
> you know if it works or not.(I suspect you already knew that... =:B )
>
> >> What exactly is the Unresolved Symbol message trying to tell me?
> >
> > Symbols are part of compiled executable code which inform linkers how to
> > join two or more pieces of compiled code together. E.G. if module Foo
> > needs to call function bar() which is part of the kernel, the module
> > loader needs to match the symbol bar in the two pieces of code and make
> > some adjustments so that the module can successfully call bar().
> >
> > If some symbols are unresolved, the two pieces of code can't talk to each
> > other, which in this case causes the module load attempt to fail.
>
> So, is this not unlike the problems one might encounter trying to compile
> source code when you forgot to #include a header file containing a
> function/
> variable that is referenced in your main.c (for example)?
>
> I guess I'm still a little confused as to where in the process the problem
> is
> occurring depmod creates a "makefile like dependency file" and this is
> where
> I am having the problem; in creating the file that describes the
> dependencies.
> So what information is depmod missing that would resolve these symbols?
>
> Kitt
-- Thanks Brian
This archive was generated by hypermail 2a24 : Thu Oct 04 2001 - 08:28:34 MDT