Olaf Hering wrote:
On Wed, Nov 08, Dave Anderson wrote:
> Olaf Hering wrote:
>
> > crash 4.0-3.9 can not read a dump file from an ia64 box running 2.6.5.
> > Is this supposed to work?
> >
> > crash -s boot/System.map-2.6.5-7.267-sn2 boot/Kerntypes-2.6.5-7.267-sn2
dump.3
>
> Well, if it did work, it would be news to me. I've certainly never run crash
> with a "Kerntypes" file as a substitute for a -g built vmlinux file.
Thats all we have right now. And sadly, I have been told that gcc will
generate different asm depending on what host the kernel is compiled
(memory config etc.). So getting the exact vmlinux again may be a
challenge with gcc3.2.
Well, that's always been the case, and that's OK. In that case,
all you have to do is compile the identical kernel source code
with -g, but also pass the System.map file of the "real" dumped
vmlinux on the command line, as in:
# crash vmlinux-rebuilt-with-g System.map-of-dumped-vmlinux dumpfile
That's the sole purpose of the System.map argument, which should
*only* be used in such a case.
What happens when you use a System.map command line argument is this:
1. crash passes its embedded gdb the vmlinux-rebuilt-with-g file,
which will most likely have many of its text addresses, and probably
all of its data addresses "shifted" up, and therefore be incorrect.
(But the data structure definitions, etc., are correct...)
2. After that, crash takes the System.map file, which contains a
list of the *correct* symbol values, goes in a back-door into gdb,
and overwrites gdb's symbol list values with the correct values.
That's what's happening when you see that init-time message:
please wait... (patching 20920 gdb minimal_symbol values)
We had to do that for RHEL 2.1, which at the time did not have a
kernel debuginfo package, so we always had to rebuild specific
kernel versions with -g for crash sessions. With RHEL3 and beyond,
the -g built vmlinux is part of each kernel's debuginfo package,
so from that point on, there has never been a need to use a
System.map file.
Dave