diff options
author | Ian Rogers <[email protected]> | 2023-06-12 20:48:17 -0700 |
---|---|---|
committer | Arnaldo Carvalho de Melo <[email protected]> | 2023-06-13 23:40:32 -0300 |
commit | 8dc26b6f718a81188519b77033eea764c9b6f732 (patch) | |
tree | a30b237810651168486b817e6f83ee0095df01f1 /scripts/gdb/linux/interrupts.py | |
parent | c7a0023a1495355e71177ebfae33d27ad97577c3 (diff) |
perf srcline: Make sentinel reading for binutils addr2line more robust
The addr2line process is sent an address then multiple function,
filename:line "records" are read. To detect the end of output a ',' is
sent and for llvm-addr2line a ',' is then read back showing the end of
addrline's output.
For binutils addr2line the ',' translates to address 0 and we expect the
bogus filename marker "??:0" (see filename_split) to be sent from
addr2line.
For some kernels address 0 may have a mapping and so a seemingly valid
inline output is given and breaking the sentinel discovery:
```
$ addr2line -e vmlinux -f -i
,
__per_cpu_start
./arch/x86/kernel/cpu/common.c:1850
```
To avoid this problem enable the address dumping for addr2line (the -a
option). If an address of 0x0000000000000000 is read then this is the
sentinel value working around the problem above.
The filename_split still needs to check for "??:0" as bogus non-zero
addresses also need handling.
Reported-by: Changbin Du <[email protected]>
Signed-off-by: Ian Rogers <[email protected]>
Tested-by: Changbin Du <[email protected]>
Cc: Adrian Hunter <[email protected]>
Cc: Alexander Shishkin <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nick Desaulniers <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Tom Rix <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Diffstat (limited to 'scripts/gdb/linux/interrupts.py')
0 files changed, 0 insertions, 0 deletions