Re: Ooops

Keith Owens (kaos@ocs.com.au)
Tue, 16 Mar 1999 15:32:43 -0800

On Tue, 16 Mar 1999 02:43:18 -0500,
"Joseph Gooch" <mrwizard@psu.edu> wrote:
>It's actually kind of
>interesting that timer_bug_msg is referenced in the trace since that's a
>const char [] definition in net/ipv4/tcp_timer.c. One would think that
>wouldn't be an executable area. And also in my System.map :
>
>c01de1c0 r rta_max
>c01de2e5 r prio2band
>c01e0200 R timer_bug_msg
>c01e13b0 r msstab
>c01e1cc0 R ide_pio_timings
>c01e1f83 r ide_hwif_to_major
>
>It's a much bigger area than the 86 bytes allocated to it in the .o file.

Both the kernel and ksymoops have to guess at what *might* be a return
address when dumping the stack. The kernel prints any addresses that
even look as if they fall within kernel or module space. ksymoops
takes those addresses and finds the nearest external symbol.

If you browse vmlinux and look for the text of timer_bug_msg, you will
find it in read only storage. Either side of timer_bug_msg are a lot
more text strings but, because these strings come from printk formats
and string assignments, they are not declared as external symbols.
Therefore there are gaps in the System.map, as you found above.

It is left for a sensible human to decide if the stack trace and
mapping to external symbols is sensible. IMHO it is better for the
kernel and ksymoops to provide as much info as possible, even if some
of it might be a little misleading.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/