[Kgdb-bugreport] Problem getting kgdb to read kernel symbols. addresses shifted?

Dave Anderson anderson at redhat.com
Mon Oct 1 15:03:41 EDT 2007

Derek Atkins wrote:
> Dave Anderson <anderson at redhat.com> writes:
>>>Hi Eric and others,
>>>I think we might be running into the issues because i386, FC7 relocatable
>>>kernel has been compiled for 16MB physical address but effectively it
>>>runs at 4MB physical address. So kernel does not run at compiled address
>>>and any kind of debugging tools reading symbol address from System.map
>>>or rom vmlinux will fail as run time symbol addresses are different.
>>>/proc/kallsyms should help though. This is one problem with shift in run
>>>time virtual address while relocating the kernel. We should be running kernel
>>>at compiled address to be able to debug it. Or enable any tools to parse
>>>/proc/kallsyms to read the shift in symbol addresses and adjust accordingly.
>>Right, crash was updated in version 4.0-4.5 to allow the use
>>of /proc/kallsyms as an alternative to the System.map file,
>>as well as adding a new --reloc command line argument.  After
>>bringing up the vmlinux file in gdb (with the "wrong" addresses),
>>all of the minimal_symbol data structures in the gdb module are
>>back-patched with the /proc/kallsyms values:
>> http://people.redhat.com/anderson/crash.changelog.html#4_0_4_5
>>It seems the benefit of configuring the kernel that way is debatable,
>>and I will do all I can to convince the RHEL-6 and beyond kernel
>>maintainers from doing it that way in the future.  But Fedora goes
>>its own way.  Seems totally lame to issue a bogus System.map file
> Well, this is kgdb, so "/proc/kallsyms" is on the target machine,
> not the host machine.  So, 'gdb' cannot read /proc/kallsyms, because,
> well, it's not local.

Well, you could just grab a copy of it, although I don't know what
gdb alone would be able to do with it...

> However, I AM building my own kernel -- so I can certainly reconfigure
> it as necessary.  What do I need to do to reconfigure my kernel to
> run at the same place it was built for?  I.e., what's changing the
> runtime from 16M to 4M and how do I make it consistent?
> Thanks!

Configure the kernel with CONFIG_PHYSICAL_START less than
or equal to CONFIG_PHYSICAL_ALIGN.  Upon rebuilding my FC7
kernel with CONFIG_PHYSICAL_START changed from 16MB to 1MB,
with CONFIG_PHYSICAL_ALIGN left at 4MB, i.e.:


The kernel gets compiled for, and runs at, a 4MB physical address:

   $ nm -Bn vmlinux | grep "^c04"
   c0400000 T _text
   c0400000 T startup_32
   c0401000 T startup_32_smp
   c0401080 t checkCPUtype
   c0401101 t is486

Setting both of them to 0x400000 also works.


More information about the kexec mailing list