Re: slowly decommission bugzilla?
Linus Torvalds <[email protected]> Sat, 28 Feb 2026 09:40:28 -0800
| Newsgroups | dev.linux.lists.ksummit |
|---|---|
| Message-ID | <CAHk-=wh3fsqZ=KUfm2cnq_D_U63Pk33Q7cs8_QYdyzbPXjE1bw@mail.gmail.com> |
On Sat, 28 Feb 2026 at 07:17, Richard Weinberger <[email protected]> wrote: > > 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. Linus