Bug 54444 - building RHL 7.1 kernel doesn't generate correct kernel symbol mangling in all cases
building RHL 7.1 kernel doesn't generate correct kernel symbol mangling in al...
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-08 11:25 EDT by Dave Wysochanski
Modified: 2015-03-04 20:09 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-11 12:02:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dave Wysochanski 2001-10-08 11:25:45 EDT
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
support
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
symbols". 
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: 
"pci_write_config_byte_R_ver_str(546edb5b)"

  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:
> update-modverfile:
>        @(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

How Reproducible:
Should be easily reproducible, as I tried many, many times to get the
correct mangling
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". 

Actual Results:
You'll get some symbols that weren't mangled/demangled correctly.

Expected Results:
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).

Additional Information:
Comment 1 Phil Knirsch 2001-10-25 10:05:21 EDT
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 ;).

Reassigning.

Read ya, Phil
Comment 2 Dave Wysochanski 2002-01-21 15:35:46 EST
Doesn't anybody care about this?  Has anyone even looked at this since I
filed it????  This bug just bit me again.
Comment 3 Arjan van de Ven 2002-02-11 12:02:02 EST
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)
Comment 4 Phil Knirsch 2002-06-19 05:32:09 EDT
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

Note You need to log in before you can comment on or make changes to this bug.