On Wed, Nov 08, Dave Anderson wrote:Well, that's always been the case, and that's OK. In that case,> 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.
# 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