Messages in this thread | | | From | Keith Owens <> | Subject | Re: Ooops | Date | 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/
| |