Re: slowly decommission bugzilla?

----- Ursprüngliche Mail -----
> Von: "Linus Torvalds" <[email protected]>
>> What we need is a mapping between symbol names and source files.
>> That's also doable. e.g. by running "nm" on all *.ko files of a allmodconfig
>> build.
> 
> For stack traces, what you actually want is
> 
> (a) a debug-info build
> 
> (b) run scripts/decode_stacktrace.sh
> 
> on the stacktrace.
> 
> That gives you not just source files and module names, but line
> numbers and inlining information too, which is really realy convenient
> for more complicated stack traces.
> 
> Apparently not enough people know about this.
> 
> For a recent example of this script output, see
> 
>   https://lore.kernel.org/all/[email protected]/
> 
> and notice how it not only disassembles the code line, but it changes
> a trace like
> 
>  uart_write+0x1ec/0x240
>  handle_tx+0x9a/0x1a0
>  caif_xmit+0x61/0x70
>  dev_hard_start_xmit+0xa6/0x1e0
> 
> into
> 
>  uart_write (drivers/tty/serial/serial_core.c:72
> drivers/tty/serial/serial_core.c:598)
>  handle_tx (drivers/net/caif/caif_serial.c:237)
>  caif_xmit (drivers/net/caif/caif_serial.c:284)
>  dev_hard_start_xmit (./include/linux/netdevice.h:4833
> ./include/linux/netdevice.h:4847 net/core/dev.c:3601
> net/core/dev.c:3617)
> 
> which is really a lot easier for people to figure out where things happened.

Of course. But I had a different use case in mind.
I thought about pasting whatever stack trace a user finds in dmesg/syslog
into a web interface to find the most suitable mailing list to report to.

*If* debuginfo and tooling is available to the user, of course they should
include the decoded stack trace to the report.
How to do that should be included in the instructions on how to report
the issue by mail.

Thanks,
//richard