[Crash-utility] - creeping schizophrenia?

[Dave Anderson]

Amit Kale wrote:
> Is vmlinux a relocatable object file in FC7? If it is, we can make gdb
> load it at a different address easily by using "add-symbol-file"
> command with offsets.
> 

It is, as well as in RHEL5 for that matter.  But until these
kernels, the typical kernel configuration has always created
kernel symbols that were unity-mapped.  (at least for the primary
kernel -- we don't care about supporting crash running on
the secondary kdump kernel).

The embedded gdb module inside of crash is invoked essentially
as "gdb vmlinux".  The "add-symbol-file" mechanics are currently
used for loading kernel module objects, but I've never even
considered using it on the same file.  Interesting concept
though, doing it on the vmlinux file itself a "second" time,
but using a base address.  I'm certainly not sure how that
would work.

The good news is that there's always been the capability in
crash to use a non-matching vmlinux, but then override the
symbol values in the vmlinux by adding the System.map file from
the "real" kernel as a command line argument.  The override
is done early on by back-patching all of the symbols that gdb
read from the non-matching vmlinux.  Unfortunately the System.map
file for these new kernels also has the "wrong" symbol values,
since they are just pulled from the vmlinux file.  I didn't notice
until yesterday that /proc/kallsyms contains the "resolved" symbol
values.  So with some additional hackery, the same back-patching
concept can be used; but I don't see how to do it "automatically",
except for live systems that have /proc/kallsyms.

> Unfortunately AFAIK core files only contain data sections and there is
> no way of specifying relocated code section addresses.
> 

Are you still talking about the vmlinux file or the kdump vmcore?

The core files aren't a problem for crash, since it only pulls
out physical memory information from the PT_LOAD segments.
And the gdb module inside of crash doesn't know anything
about core files -- it just knows that it was invoked
as "gdb vmlinux", regardless whether crash itself is running
against a dumpfile or a live system.

> Perhaps we can create a /proc/maps file for kernel just like
> /proc/self/maps for processes.

Whatever -- although that won't help when running crash on dumpfiles
on systems other than the host where the crash took place, right?
Like I said, there may be something in the vmlinux file, but
I couldn't find anything obvious.

Dave