Actually, crash is reading all the symbols it really needs.
crash-utility-bounces@xxxxxxxxxx wrote on 29.09.2006 17:38:53:> ville.mattila@xxxxxxxxxxxxx wrote:
>
>
> Right -- unfortunately the recompilation of the exact same kernel may
> cause a shift in kernel text addresses, which throws off the line number
> information. You might try just running "crash vmlinux.dbg vmcore" and
> see what happens. If it doesn't complain about a mis-match, you should
> be OK. But if there is a shift in the text addressing, then there's a good
> chance that it will propagate up into the static data addressing as well,
> and the mis-match ensues...Thanks for very good explanation.
I tried vmlinux.dbg and got
WARNING: could not find MAGIC_START!
crash: ../smp-dbg/boot/vmlinux-2.6.15.7+smp and crashdump.2006-08-15-11-13-23 do not match!I should mention that I had to patch crash so that it can read all the symbols. I originally
got symbol overflows. e.g crash gave output:
crash: symbol count overflow (__func__.1)
crash: symbol count overflow (__func__.2)
crash: symbol count overflow (__func__.3)
crash: symbol count overflow (__func__.0)
I'm guessing that you changed the 200 value in patch_kernel_symbol()
to use a larger number here:
switch (c = get_syment_array(req->name, sp_array, 200))
In the gdb symbol back-patch operation required in your case,
there are more that 200 instances of "__func__.1", "__func__.2",
etc, and after 200 instances have been back-patched, the rest
of them are just left alone. Since crash never uses them, it's
harmless.
In any case, those "__func__.#" symbols should not be cached
at all in the crash utility's list of symbols. For example, in
the
ppc64.c ppc64_verify_symbol() function, those symbols are
rejected. Each processor type has its own xxx_verify_symbol()
function, which can be used to weed out those types of
functions. I should probably do the same thing for the other
arches.
Nope, that won't help. If you can simply run the newly-built kernel,
To get "dis -l" to work, should I just compile the vmlinux "-g" and extract the debug
info to .debug file e.g, Like RHEL 3.0 does?
then you're in business. But for a dumpfile created while running the
older kernel, or for live-system analysis on a system running the old
kernel, you're just not going to get line numbers. The only other thing
I can suggest is to comment out this line in patch_kernel_symbol()
st->flags |= GDB_SYMS_PATCHED;
...and keep in mind that the "dis -l" output may not be correct.
As I recall, the first "shift" in text addresses may occur well
into the text segment, and therefore for all text that occurs
before the shift, the line number info will still be legitimate.
Dave
-- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
