scripts/decode_stacktrace.sh: fix decoding of lines with an additional info

Since commit bdf8eafbf7f5 ("arm64: stacktrace: report source of unwind
data") a stack trace line can contain an additional

scripts/decode_stacktrace.sh: fix decoding of lines with an additional info

Since commit bdf8eafbf7f5 ("arm64: stacktrace: report source of unwind
data") a stack trace line can contain an additional info field that was not
present before, in the form of one or more letters in parentheses. E.g.:

[ 504.517915] led_sysfs_enable+0x54/0x80 (P)
^^^

When this is present, decode_stacktrace decodes the line incorrectly:

[ 504.517915] led_sysfs_enable+0x54/0x80 P

Extend parsing to decode it correctly:

[ 504.517915] led_sysfs_enable (drivers/leds/led-core.c:455 (discriminator 7)) (P)

The regex to match such lines assumes the info can be extended in the
future to other uppercase characters, and will need to be extended in case
other characters will be used. Using a much more generic regex might incur
in false positives, so this looked like a good tradeoff.

Link: https://lkml.kernel.org/r/20241230-decode_stacktrace-fix-info-v1-1-984910659173@bootlin.com
Fixes: bdf8eafbf7f5 ("arm64: stacktrace: report source of unwind data")
Signed-off-by: Luca Ceresoli <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Mark Brown <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Miroslav Benes <[email protected]>
Cc: Puranjay Mohan <[email protected]>
Cc: Thomas Petazzoni <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

scripts/decode_stacktrace.sh: remove trailing space

decode_stacktrace.sh adds a trailing space at the end of the decoded stack
if the module is not set (in most of the lines), which makes the some
l

scripts/decode_stacktrace.sh: remove trailing space

decode_stacktrace.sh adds a trailing space at the end of the decoded stack
if the module is not set (in most of the lines), which makes the some
lines of the stack having trailing space and some others not.

Do not add an extra space at the end of the line if module is not set,
adding consistency in output formatting.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Breno Leitao <[email protected]>
Reviewed-by: Elliot Berman <[email protected]>
Reviewed-by: Carlos Llamas <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Cc: Bjorn Andersson <[email protected]>
Cc: Luca Ceresoli <[email protected]>
Cc: Xiong Nandi <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

scripts/decode_stacktrace.sh: add '-h' flag

When no parameters are passed, the usage instructions are presented only
when debuginfod-find is not found. This makes sense because with
debuginfod none

scripts/decode_stacktrace.sh: add '-h' flag

When no parameters are passed, the usage instructions are presented only
when debuginfod-find is not found. This makes sense because with
debuginfod none of the positional parameters are needed. However it means
that users having debuginfod-find installed will have no chance of reading
the usage text without opening the file.

Many programs have a '-h' flag to get the usage, so add such a flag.
Invoking 'scripts/decode_stacktrace.sh -h' will now show the usage text
and exit.

Link: https://lkml.kernel.org/r/20240823-decode_stacktrace-find_module-improvements-v2-3-d7a57d35558b@bootlin.com
Signed-off-by: Luca Ceresoli <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Cc: Alexis Lothoré (eBPF Foundation) <[email protected]>
Cc: Konstantin Khlebnikov <[email protected]>
Cc: Sasha Levin <[email protected]>
Cc: Thomas Petazzoni <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

scripts/decode_stacktrace.sh: clarify command line

The syntax as expressed by usage() is not entirely correct: "<modules
path>" cannot be passed without "<base path>|auto". Additionally human
readi

scripts/decode_stacktrace.sh: clarify command line

The syntax as expressed by usage() is not entirely correct: "<modules
path>" cannot be passed without "<base path>|auto". Additionally human
reading of this syntax can be subject to misunderstanding due the mixture
of '|' and '[]'.

Improve readability in various ways:
* rewrite using two lines for the two allowed usages
* add square brackets around "<vmlinux>" as it is optional when using
debuginfod-find
* move "<modules path>" to inside the square brackets of the 2nd
positional parameter
* use underscores instead of spaces in <...> strings

Link: https://lkml.kernel.org/r/20240823-decode_stacktrace-find_module-improvements-v2-2-d7a57d35558b@bootlin.com
Signed-off-by: Luca Ceresoli <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Cc: Alexis Lothoré (eBPF Foundation) <[email protected]>
Cc: Konstantin Khlebnikov <[email protected]>
Cc: Sasha Levin <[email protected]>
Cc: Thomas Petazzoni <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

scripts/decode_stacktrace.sh: remove find_module recursion and improve error reporting

Patch series "scripts/decode_stacktrace.sh: improve error reporting and
usability", v2.

This small series impr

scripts/decode_stacktrace.sh: remove find_module recursion and improve error reporting

Patch series "scripts/decode_stacktrace.sh: improve error reporting and
usability", v2.

This small series improves usability of scripts/decode_stacktrace.sh by
improving the usage text and correctly reporting when modules are built
without debugging symbols.


This patch (of 3):

The find_module() function can fail for two reasons:

* the module was not found
* the module was found but without debugging info

In both cases the user is reported the same error:

WARNING! Modules path isn't set, but is needed to parse this symbol

This is misleading in case the modules path is set correctly.

find_module() is currently implemented as a recursive function based on
global variables in order to check up to 4 different paths. This is not
straightforward to read and even less to modify.

Besides, the debuginfo code at the beginning of find_module() is executed
identically every time the function is entered, i.e. up to 4 times per
each module search due to recursion.

To be able to improve error reporting, first rewrite the find_module()
function to remove recursion. The new version of the function iterates
over all the same (up to 4) paths as before and for each of them does the
same checks as before. At the end of the iteration it is now able to
print an appropriate error message, so that has been moved from the caller
into find_module().

Finally, when the module is found but without debugging info, mention the
two Kconfig variables one needs to set in order to have the needed
debugging symbols.

Link: https://lkml.kernel.org/r/20240823-decode_stacktrace-find_module-improvements-v2-0-d7a57d35558b@bootlin.com
Link: https://lkml.kernel.org/r/20240823-decode_stacktrace-find_module-improvements-v2-1-d7a57d35558b@bootlin.com
Signed-off-by: Luca Ceresoli <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Cc: Alexis Lothoré (eBPF Foundation) <[email protected]>
Cc: Konstantin Khlebnikov <[email protected]>
Cc: Luca Ceresoli <[email protected]>
Cc: Sasha Levin <[email protected]>
Cc: Thomas Petazzoni <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

scripts/decode_stacktrace.sh: nix-ify

nix only puts /usr/bin/env at the standard location (as required by
posix), so shebangs have to be tweaked.

Link: https://lkml.kernel.org/r/20240817215025.1616

scripts/decode_stacktrace.sh: nix-ify

nix only puts /usr/bin/env at the standard location (as required by
posix), so shebangs have to be tweaked.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Kent Overstreet <[email protected]>
Cc: Bjorn Andersson <[email protected]>
Cc: Elliot Berman <[email protected]>
Cc: Xiong Nandi <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

scripts/decode_stacktrace.sh: better support to ARM32 module stack trace

Sometimes there are special characters around module names in stack
traces, such as ARM32 with BACKTRACE_VERBOSE in "(%pS)" f

scripts/decode_stacktrace.sh: better support to ARM32 module stack trace

Sometimes there are special characters around module names in stack
traces, such as ARM32 with BACKTRACE_VERBOSE in "(%pS)" format, such as:
[<806e4845>] (dump_stack_lvl) from [<7f806013>] (hello_init+0x13/0x1000
[test])

In this case, $module will be "[test])", the trace can be decoded by
stripping the right parenthesis first: (dump_stack_lvl) from hello_init
(/foo/test.c:10) test.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Xiong Nandi <[email protected]>
Suggested-by: Elliot Berman <[email protected]>
Cc: Bjorn Andersson <[email protected]>
Cc: Carlos Llamas <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

scripts/decode_stacktrace.sh: wrap nm with UTIL_PREFIX and UTIL_SUFFIX

Patch series "scripts/decode_stacktrace.sh: better support to ARM32".


This patch (of 2):

Since System.map is generated by cr

scripts/decode_stacktrace.sh: wrap nm with UTIL_PREFIX and UTIL_SUFFIX

Patch series "scripts/decode_stacktrace.sh: better support to ARM32".


This patch (of 2):

Since System.map is generated by cross-compile nm tool, we should use it here
too. Otherwise host nm may not recognize ARM Thumb-2 instruction address well.

Link: https://lkml.kernel.org/r/[email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Xiong Nandi <[email protected]>
Reviewed-by: Elliot Berman <[email protected]>
Cc: Bjorn Andersson <[email protected]>
Cc: Carlos Llamas <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

scripts/decode_stacktrace.sh: optionally use LLVM utilities

GNU's addr2line can have problems parsing a vmlinux built with LLVM,
particularly when LTO was used. In order to decode the traces correc

scripts/decode_stacktrace.sh: optionally use LLVM utilities

GNU's addr2line can have problems parsing a vmlinux built with LLVM,
particularly when LTO was used. In order to decode the traces correctly
this patch adds the ability to switch to LLVM's utilities readelf and
addr2line. The same approach is followed by Will in [1].

Before:
$ scripts/decode_stacktrace.sh vmlinux < kernel.log
[17716.240635] Call trace:
[17716.240646] skb_cow_data (??:?)
[17716.240654] esp6_input (ld-temp.o:?)
[17716.240666] xfrm_input (ld-temp.o:?)
[17716.240674] xfrm6_rcv (??:?)
[...]

After:
$ LLVM=1 scripts/decode_stacktrace.sh vmlinux < kernel.log
[17716.240635] Call trace:
[17716.240646] skb_cow_data (include/linux/skbuff.h:2172 net/core/skbuff.c:4503)
[17716.240654] esp6_input (net/ipv6/esp6.c:977)
[17716.240666] xfrm_input (net/xfrm/xfrm_input.c:659)
[17716.240674] xfrm6_rcv (net/ipv6/xfrm6_input.c:172)
[...]

Note that one could set CROSS_COMPILE=llvm- instead to hack around this
issue. However, doing so can break the decodecode routine as it will
force the selection of other LLVM utilities down the line e.g. llvm-as.

[1] https://lore.kernel.org/all/[email protected]/

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Carlos Llamas <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Reviewed-by: Elliot Berman <[email protected]>
Tested-by: Justin Stitt <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: John Stultz <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Tom Rix <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

scripts/decode_stacktrace.sh: strip unexpected CR from lines

When the kernel log is acquired over a serial cable it is not uncommon for
the log to contain carriage return characters, in addition to

scripts/decode_stacktrace.sh: strip unexpected CR from lines

When the kernel log is acquired over a serial cable it is not uncommon for
the log to contain carriage return characters, in addition to the expected
line feeds.

When this output is feed into decode_stacktrace.sh, handle_line() fails to
strip the trailing ']' off the module name, which results in find_module()
not being able to find the referred to kernel module. This is reported to
the user as:

WARNING! Modules path isn't set, but is needed to parse this symbol

The solution is to reconfigure the serial port, or to strip the carriage
returns from the log, but this isn't obvious from the error reported by
the script.

Instead, make decode_stacktrace.sh more user friendly by stripping the
trailing carriage return.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

scripts: decode_stacktrace: demangle Rust symbols

Recent versions of both Binutils (`c++filt`) and LLVM (`llvm-cxxfilt`)
provide Rust v0 mangling support.

Reviewed-by: Kees Cook <keescook@chromium.

scripts: decode_stacktrace: demangle Rust symbols

Recent versions of both Binutils (`c++filt`) and LLVM (`llvm-cxxfilt`)
provide Rust v0 mangling support.

Reviewed-by: Kees Cook <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Co-developed-by: Alex Gaynor <[email protected]>
Signed-off-by: Alex Gaynor <[email protected]>
Co-developed-by: Wedson Almeida Filho <[email protected]>
Signed-off-by: Wedson Almeida Filho <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

scripts/decode_stacktrace.sh: support old bash version

Old bash version don't support associative array variables. Avoid to use
associative array variables to avoid error.

Without this, old bash v

scripts/decode_stacktrace.sh: support old bash version

Old bash version don't support associative array variables. Avoid to use
associative array variables to avoid error.

Without this, old bash version will report error as fellowing
[ 15.954042] Kernel panic - not syncing: sysrq triggered crash
[ 15.955252] CPU: 1 PID: 167 Comm: sh Not tainted 5.18.0-rc1-00208-gb7d075db2fd5 #4
[ 15.956472] Hardware name: Hobot J5 Virtual development board (DT)
[ 15.957856] Call trace:
./scripts/decode_stacktrace.sh: line 128: ,dump_backtrace: syntax error: operand expected (error token is ",dump_backtrace")

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Schspa Shi <[email protected]>
Cc: Stephen Boyd <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

scripts/decode_stacktrace.sh: indicate 'auto' can be used for base path

Add "auto" to the usage message so that it's a little clearer that you can
pass "auto" as the second argument. When passing "

scripts/decode_stacktrace.sh: indicate 'auto' can be used for base path

Add "auto" to the usage message so that it's a little clearer that you can
pass "auto" as the second argument. When passing "auto" the script tries
to find the base path automatically instead of requiring it be passed on
the commandline. Also use [<variable>] to indicate the variable argument
and that it is optional so that we can differentiate from the literal
"auto" that should be passed.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Stephen Boyd <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Jessica Yu <[email protected]>
Cc: Evan Green <[email protected]>
Cc: Hsin-Yi Wang <[email protected]>
Cc: Konstantin Khlebnikov <[email protected]>
Cc: Sasha Levin <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: Baoquan He <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Dave Young <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: Rasmus Villemoes <[email protected]>
Cc: Sergey Senozhatsky <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vivek Goyal <[email protected]>
Cc: Will Deacon <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/decode_stacktrace.sh: silence stderr messages from addr2line/nm

Sometimes if you're using tools that have linked things improperly or have
new features/sections that older tools don't expect

scripts/decode_stacktrace.sh: silence stderr messages from addr2line/nm

Sometimes if you're using tools that have linked things improperly or have
new features/sections that older tools don't expect you'll see warnings
printed to stderr. We don't really care about these warnings, so let's
just silence these messages to cleanup output of this script.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Stephen Boyd <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Jessica Yu <[email protected]>
Cc: Evan Green <[email protected]>
Cc: Hsin-Yi Wang <[email protected]>
Cc: Konstantin Khlebnikov <[email protected]>
Cc: Sasha Levin <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: Baoquan He <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Dave Young <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: Rasmus Villemoes <[email protected]>
Cc: Sergey Senozhatsky <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vivek Goyal <[email protected]>
Cc: Will Deacon <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/decode_stacktrace.sh: support debuginfod

Now that stacktraces contain the build ID information we can update this
script to use debuginfod-find to locate the debuginfo for the vmlinux and
mo

scripts/decode_stacktrace.sh: support debuginfod

Now that stacktraces contain the build ID information we can update this
script to use debuginfod-find to locate the debuginfo for the vmlinux and
modules automatically. This can replace the existing code that requires
specifying a path to vmlinux or tries to find the vmlinux and modules
automatically by using the release number. Work it into the script as a
fallback option if the vmlinux isn't specified on the commandline.

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Stephen Boyd <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: Jessica Yu <[email protected]>
Cc: Evan Green <[email protected]>
Cc: Hsin-Yi Wang <[email protected]>
Cc: Konstantin Khlebnikov <[email protected]>
Cc: Sasha Levin <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: Baoquan He <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Dave Young <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Rasmus Villemoes <[email protected]>
Cc: Sergey Senozhatsky <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Vivek Goyal <[email protected]>
Cc: Will Deacon <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/decode_stacktrace.sh: guess path to vmlinux by release name

Add option decode_stacktrace -r <release> to specify only release name.
This is enough to guess standard paths to vmlinux and modu

scripts/decode_stacktrace.sh: guess path to vmlinux by release name

Add option decode_stacktrace -r <release> to specify only release name.
This is enough to guess standard paths to vmlinux and modules:

$ echo -e 'schedule+0x0/0x0
tap_open+0x0/0x0 [tap]' |
./scripts/decode_stacktrace.sh -r 5.4.0-37-generic
schedule (kernel/sched/core.c:4138)
tap_open (drivers/net/tap.c:502) tap

Signed-off-by: Konstantin Khlebnikov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Cc: Sasha Levin <[email protected]>
Link: http://lkml.kernel.org/r/159282923334.248444.2399153100007347838.stgit@buzz
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/decode_stacktrace.sh: guess path to modules

Try to find module in directory with vmlinux (for fresh build). Then try
standard paths where debuginfo are usually placed. Pick first file whic

scripts/decode_stacktrace.sh: guess path to modules

Try to find module in directory with vmlinux (for fresh build). Then try
standard paths where debuginfo are usually placed. Pick first file which
have elf section '.debug_line'.

Before:

$ echo 'tap_open+0x0/0x0 [tap]' |
./scripts/decode_stacktrace.sh /usr/lib/debug/boot/vmlinux-5.4.0-37-generic
WARNING! Modules path isn't set, but is needed to parse this symbol
tap_open+0x0/0x0 tap

After:

$ echo 'tap_open+0x0/0x0 [tap]' |
./scripts/decode_stacktrace.sh /usr/lib/debug/boot/vmlinux-5.4.0-37-generic
tap_open (drivers/net/tap.c:502) tap

Signed-off-by: Konstantin Khlebnikov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Cc: Sasha Levin <[email protected]>
Link: http://lkml.kernel.org/r/159282923068.248444.5461337458421616083.stgit@buzz
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/decode_stacktrace.sh: guess basepath if not specified

Guess path to kernel sources using known location of symbol "kernel_init".
Make basepath argument optional.

Before:

$ echo 'vfs_open+0

scripts/decode_stacktrace.sh: guess basepath if not specified

Guess path to kernel sources using known location of symbol "kernel_init".
Make basepath argument optional.

Before:

$ echo 'vfs_open+0x0/0x0' | ./scripts/decode_stacktrace.sh vmlinux ""
vfs_open (home/khlebnikov/src/linux/fs/open.c:912)

After:

$ echo 'vfs_open+0x0/0x0' | ./scripts/decode_stacktrace.sh vmlinux
vfs_open (fs/open.c:912)

Signed-off-by: Konstantin Khlebnikov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Cc: Sasha Levin <[email protected]>
Link: http://lkml.kernel.org/r/159282922803.248444.2379229451667913634.stgit@buzz
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/decode_stacktrace.sh: skip missing symbols

For now script turns missing symbols into '0' and make bogus decode. Skip
them instead. Also simplify parsing output of 'nm'.

Before:

$ echo 'x

scripts/decode_stacktrace.sh: skip missing symbols

For now script turns missing symbols into '0' and make bogus decode. Skip
them instead. Also simplify parsing output of 'nm'.

Before:

$ echo 'xxx+0x0/0x0' | ./scripts/decode_stacktrace.sh vmlinux ""
xxx (home/khlebnikov/src/linux/./arch/x86/include/asm/processor.h:398)

After:

$ echo 'xxx+0x0/0x0' | ./scripts/decode_stacktrace.sh vmlinux ""
xxx+0x0/0x0

Signed-off-by: Konstantin Khlebnikov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Cc: Sasha Levin <[email protected]>
Link: http://lkml.kernel.org/r/159282922499.248444.4883465570858385250.stgit@buzz
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/decode_stacktrace: strip basepath from all paths

Currently the basepath is removed only from the beginning of the string.
When the symbol is inlined and there's multiple line outputs of
addr

scripts/decode_stacktrace: strip basepath from all paths

Currently the basepath is removed only from the beginning of the string.
When the symbol is inlined and there's multiple line outputs of
addr2line, only the first line would have basepath removed.

Change to remove the basepath prefix from all lines.

Fixes: 31013836a71e ("scripts/decode_stacktrace: match basepath using shell prefix operator, not regex")
Co-developed-by: Shik Chen <[email protected]>
Signed-off-by: Pi-Hsun Shih <[email protected]>
Signed-off-by: Shik Chen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Cc: Sasha Levin <[email protected]>
Cc: Nicolas Boichat <[email protected]>
Cc: Jiri Slaby <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/decode_stacktrace: warn when modpath is needed but is unset

When a user tries to parse a symbol located inside a module he must have
modpath set. Otherwise, decode_stacktrace won't be able t

scripts/decode_stacktrace: warn when modpath is needed but is unset

When a user tries to parse a symbol located inside a module he must have
modpath set. Otherwise, decode_stacktrace won't be able to parse the
symbol correctly.

Right now the failure is silent and easily missed by the user. What's
worse is that by the time the user realizes what happened (or someone on
LKML asks him to add the modpath and re-run), he might have already got
rid of the vmlinux/modules.

Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/decode_stacktrace: Accept dash/underscore in modules

The manpage for modprobe mentions that dashes and underscores are
treated interchangeably in module names. The stack trace dumps seem to

scripts/decode_stacktrace: Accept dash/underscore in modules

The manpage for modprobe mentions that dashes and underscores are
treated interchangeably in module names. The stack trace dumps seem to
print module names with underscores. Use bash to replace _ with the
pattern [-_] so that file names with dashes or underscores can be found.

For example, this line:
[ 27.919759] hda_widget_sysfs_init+0x2b8/0x3a5 [snd_hda_core]

should find a module named snd-hda-core.ko.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Evan Green <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Acked-by: Konstantin Khlebnikov <[email protected]>
Cc: Stephen Rothwell <[email protected]>
Cc: Douglas Anderson <[email protected]>
Cc: Evan Green <[email protected]>
Cc: Nicolas Boichat <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Manuel Traut <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/decode_stacktrace: look for modules with .ko.debug extension

In Chromium OS kernel builds, we split the debug information as .ko.debug
files, and that's what decode_stacktrace.sh needs to us

scripts/decode_stacktrace: look for modules with .ko.debug extension

In Chromium OS kernel builds, we split the debug information as .ko.debug
files, and that's what decode_stacktrace.sh needs to use.

Relax objfile matching rule to allow any .ko* file to be matched.

[[email protected]: add quotes around name pattern]
Link: http://lkml.kernel.org/r/[email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Nicolas Boichat <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Konstantin Khlebnikov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/decode_stacktrace: match basepath using shell prefix operator, not regex

The basepath may contain special characters, which would confuse the regex
matcher. ${var#prefix} does the right thi

scripts/decode_stacktrace: match basepath using shell prefix operator, not regex

The basepath may contain special characters, which would confuse the regex
matcher. ${var#prefix} does the right thing.

Link: http://lkml.kernel.org/r/[email protected]
Fixes: 67a28de47faa8358 ("scripts/decode_stacktrace: only strip base path when a prefix of the path")
Signed-off-by: Nicolas Boichat <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

scripts/decode_stacktrace.sh: prefix addr2line with $CROSS_COMPILE

At least for ARM64 kernels compiled with the crosstoolchain from
Debian/stretch or with the toolchain from kernel.org the line numb

scripts/decode_stacktrace.sh: prefix addr2line with $CROSS_COMPILE

At least for ARM64 kernels compiled with the crosstoolchain from
Debian/stretch or with the toolchain from kernel.org the line number is
not decoded correctly by 'decode_stacktrace.sh':

$ echo "[ 136.513051] f1+0x0/0xc [kcrash]" | \
CROSS_COMPILE=/opt/gcc-8.1.0-nolibc/aarch64-linux/bin/aarch64-linux- \
./scripts/decode_stacktrace.sh /scratch/linux-arm64/vmlinux \
/scratch/linux-arm64 \
/nfs/debian/lib/modules/4.20.0-devel
[ 136.513051] f1 (/linux/drivers/staging/kcrash/kcrash.c:68) kcrash

If addr2line from the toolchain is used the decoded line number is correct:

[ 136.513051] f1 (/linux/drivers/staging/kcrash/kcrash.c:57) kcrash

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Manuel Traut <[email protected]>
Acked-by: Konstantin Khlebnikov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...