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: