Description of Problem:
My goal was to use 'kgdb' to debug a linux kernel module that I was
working on. To this end, I started with the 2.4.2 kernel sources (the
RHL 7.1 kernel), and downloaded the patch for kgdb (see
kgdb.sourceforge.net). I then proceeded to a "make menuconfig".
According to the kgdb site, module support is somewhat limited in
kgdb-built kernels, so you need to compile everthing that you need
(i.e. SCSI drivers) into the kernel. I did that, but also left module
in the kernel (I had my own kernel module that I wanted to debug later),
and proceeded to "make dep; make bzImage". I ran into an interesting
problem though involving kernel symbol mangling.
There's an option in the kernel build setup (i.e. "make menuconfig")
that is something like "set version information on all module/kernel
Selecting this changes kernel symbols to have a code checksum appended
to the end of them. So for example, the kernel symbol
"pci_write_config_byte" would be mangled to
"pci_write_config_byte_Rsmp_546edb5b", where 58ac8991 is the checksum of
the routine 'pci_write_config_byte', and it's a multiprocessor build. The
kernel configuration allows you to turn this off, but the problem was, it
didn't really work very well for all symbols. Some of the actual kernel
symbols I was getting looked like this:
I surmised that what was happening was that "_ver_str" was a macro
somewhere, the preprocessor was being used to either select kernel
symbol mangling or use normal kernel symbols, and for whatever reason
this macro wasn't being defined for all symbols. I found the definition
of "_ver_str" in the following file:
/usr/src/linux/include/linux/rhconfig.h. The problem turned out to be that
another header file, /usr/src/linux/include/linux/modversions.h originally
included "rhconfig.h", but after a "make dep", it no longer included the
file. This was causing various kernel symbols to be generated incorrectly.
This in itself wouldn't have been noticed by me if it weren't for the fact
that I was building my own module which was not located in the kernel tree.
When my module was built, it generated the correct kernel symbol mangling
(my guess is because the Makefiles I was using properly included
"rhconfig.h"), and when I went to load the module, I got kernel symbol
mismatches and the module wouldn't load.
I ultimately traced this problem to one line in Rules.make, under the
"update-modverfile" rule. I changed the rule to force "modversions.h" to
always include the "rhconfig.h" file:
> @(echo "#ifndef _LINUX_MODVERSIONS_H";\
> echo "#define _LINUX_MODVERSIONS_H"; \
> echo "#include <linux/rhconfig.h>"; \
> echo "#include <linux/modsetver.h>"; \
Once I fixed Rules.make, all kernel symbols were mangled correctly.
Version-Release number of selected component (if applicable):
RHL 7.1 kernel sources (2.4
Should be easily reproducible, as I tried many, many times to get the
and couldn't do it until I changed the Rules.make file.
Steps to Reproduce:
1. take original kernel src rpm from redhat for 7.1
2. configure the kernel as described above
3. do a "strings vmlinx | grep _ver_str".
You'll get some symbols that weren't mangled/demangled correctly.
You should get nothing from the grep (i.e. symbol "foo" should be either
just "foo" or "foo_R12345678", where 12345678 is the checksum for
'foo', and this is a uniprocessor build).
Erhhh, this is clearly a kernel problem, not a kernelcfg problem (which is a
program with which you can graphically edit the modules.conf file ;).
Read ya, Phil
Doesn't anybody care about this? Has anyone even looked at this since I
filed it???? This bug just bit me again.
If you patch such an intrusive patch in, you need to run "make mrproper" first
to remove all now obsolete .ver files.
More recent kernels come with a "kernel-debug" which already has the ikd
patchset included (eg the kernel debugger)
As arjan already pointed out, this is a not a bug but a usage problem. The
description on how to do proper rebuilds is given, so i close this bug now.
Read ya, Phil