- 02 Feb, 2023 10 commits
-
-
Adrian Hunter authored
For x86_64, the GNU linker is putting IFUNC information in the relocation addend, so use it to try to find a symbol for plt entries that refer to IFUNCs. Example: Before: $ cat tstpltlib.c void fn1(void) {} void fn2(void) {} void fn3(void) {} void fn4(void) {} $ cat tstpltifunc.c #include <stdio.h> void thing1(void) { printf("thing1\n"); } void thing2(void) { printf("thing2\n"); } typedef void (*thing_fn_t)(void); thing_fn_t thing_ifunc(void) { int x; if (x & 1) return thing2; return thing1; } void thing(void) __attribute__ ((ifunc ("thing_ifunc"))); void fn1(void); void fn2(void); void fn3(void); void fn4(void); int main() { fn4(); fn1(); thing(); fn2(); fn3(); return 0; } $ gcc --version gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -Wall -Wextra -shared -o libtstpltlib.so tstpltlib.c $ gcc -Wall -Wextra -Wno-uninitialized -o tstpltifunc tstpltifunc.c -L . -ltstpltlib -Wl,-rpath="$(pwd)" $ readelf -rW tstpltifunc | grep -A99 plt Relocation section '.rela.plt' at offset 0x738 contains 8 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000003f98 0000000300000007 R_X86_64_JUMP_SLOT 0000000000000000 puts@GLIBC_2.2.5 + 0 0000000000003fa8 0000000400000007 R_X86_64_JUMP_SLOT 0000000000000000 __stack_chk_fail@GLIBC_2.4 + 0 0000000000003fb0 0000000500000007 R_X86_64_JUMP_SLOT 0000000000000000 fn1 + 0 0000000000003fb8 0000000600000007 R_X86_64_JUMP_SLOT 0000000000000000 fn3 + 0 0000000000003fc0 0000000800000007 R_X86_64_JUMP_SLOT 0000000000000000 fn4 + 0 0000000000003fc8 0000000900000007 R_X86_64_JUMP_SLOT 0000000000000000 fn2 + 0 0000000000003fd0 0000000b00000007 R_X86_64_JUMP_SLOT 0000000000000000 getrandom@GLIBC_2.25 + 0 0000000000003fa0 0000000000000025 R_X86_64_IRELATIVE 125d $ perf record -e intel_pt//u --filter 'filter main @ ./tstpltifunc' ./tstpltifunc thing2 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.016 MB perf.data ] $ perf script --itrace=be --ns -F+flags,-event,+addr,-period,-comm,-tid,-cpu,-dso 21860.073683659: tr strt 0 [unknown] => 561e212c42be main+0x0 21860.073683659: tr end call 561e212c42c6 main+0x8 => 561e212c4110 fn4@plt+0x0 21860.073683661: tr strt 0 [unknown] => 561e212c42cb main+0xd 21860.073683661: tr end call 561e212c42cb main+0xd => 561e212c40f0 fn1@plt+0x0 21860.073683661: tr strt 0 [unknown] => 561e212c42d0 main+0x12 21860.073683661: tr end call 561e212c42d0 main+0x12 => 561e212c40d0 offset_0x10d0@plt+0x0 21860.073698451: tr strt 0 [unknown] => 561e212c42d5 main+0x17 21860.073698451: tr end call 561e212c42d5 main+0x17 => 561e212c4120 fn2@plt+0x0 21860.073698451: tr strt 0 [unknown] => 561e212c42da main+0x1c 21860.073698451: tr end call 561e212c42da main+0x1c => 561e212c4100 fn3@plt+0x0 21860.073698452: tr strt 0 [unknown] => 561e212c42df main+0x21 21860.073698452: tr end return 561e212c42e5 main+0x27 => 7fb51cc29d90 __libc_start_call_main+0x80 After: $ perf script --itrace=be --ns -F+flags,-event,+addr,-period,-comm,-tid,-cpu,-dso 21860.073683659: tr strt 0 [unknown] => 561e212c42be main+0x0 21860.073683659: tr end call 561e212c42c6 main+0x8 => 561e212c4110 fn4@plt+0x0 21860.073683661: tr strt 0 [unknown] => 561e212c42cb main+0xd 21860.073683661: tr end call 561e212c42cb main+0xd => 561e212c40f0 fn1@plt+0x0 21860.073683661: tr strt 0 [unknown] => 561e212c42d0 main+0x12 21860.073683661: tr end call 561e212c42d0 main+0x12 => 561e212c40d0 thing_ifunc@plt+0x0 21860.073698451: tr strt 0 [unknown] => 561e212c42d5 main+0x17 21860.073698451: tr end call 561e212c42d5 main+0x17 => 561e212c4120 fn2@plt+0x0 21860.073698451: tr strt 0 [unknown] => 561e212c42da main+0x1c 21860.073698451: tr end call 561e212c42da main+0x1c => 561e212c4100 fn3@plt+0x0 21860.073698452: tr strt 0 [unknown] => 561e212c42df main+0x21 21860.073698452: tr end return 561e212c42e5 main+0x27 => 7fb51cc29d90 __libc_start_call_main+0x80 Reviewed-by:Namhyung Kim <namhyung@kernel.org> Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20230131131625.6964-6-adrian.hunter@intel.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Adrian Hunter authored
To assist with synthesizing plt symbols for IFUNCs, record whether a symbol is an alias of an IFUNC symbol. Reviewed-by:
-
Adrian Hunter authored
For x86, with the addition of IFUNCs, relocation information becomes disordered with respect to plt. Correct that by sorting the relocations by offset. Example: Before: $ cat tstpltlib.c void fn1(void) {} void fn2(void) {} void fn3(void) {} void fn4(void) {} $ cat tstpltifunc.c #include <stdio.h> void thing1(void) { printf("thing1\n"); } void thing2(void) { printf("thing2\n"); } typedef void (*thing_fn_t)(void); thing_fn_t thing_ifunc(void) { int x; if (x & 1) return thing2; return thing1; } void thing(void) __attribute__ ((ifunc ("thing_ifunc"))); void fn1(void); void fn2(void); void fn3(void); void fn4(void); int main() { fn4(); fn1(); thing(); fn2(); fn3(); return 0; } $ gcc --version gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -Wall -Wextra -shared -o libtstpltlib.so tstpltlib.c $ gcc -Wall -Wextra -Wno-uninitialized -o tstpltifunc tstpltifunc.c -L . -ltstpltlib -Wl,-rpath="$(pwd)" $ readelf -rW tstpltifunc | grep -A99 plt Relocation section '.rela.plt' at offset 0x738 contains 8 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 0000000000003f98 0000000300000007 R_X86_64_JUMP_SLOT 0000000000000000 puts@GLIBC_2.2.5 + 0 0000000000003fa8 0000000400000007 R_X86_64_JUMP_SLOT 0000000000000000 __stack_chk_fail@GLIBC_2.4 + 0 0000000000003fb0 0000000500000007 R_X86_64_JUMP_SLOT 0000000000000000 fn1 + 0 0000000000003fb8 0000000600000007 R_X86_64_JUMP_SLOT 0000000000000000 fn3 + 0 0000000000003fc0 0000000800000007 R_X86_64_JUMP_SLOT 0000000000000000 fn4 + 0 0000000000003fc8 0000000900000007 R_X86_64_JUMP_SLOT 0000000000000000 fn2 + 0 0000000000003fd0 0000000b00000007 R_X86_64_JUMP_SLOT 0000000000000000 getrandom@GLIBC_2.25 + 0 0000000000003fa0 0000000000000025 R_X86_64_IRELATIVE 125d $ perf record -e intel_pt//u --filter 'filter main @ ./tstpltifunc' ./tstpltifunc thing2 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.029 MB perf.data ] $ perf script --itrace=be --ns -F+flags,-event,+addr,-period,-comm,-tid,-cpu,-dso 20417.302513948: tr strt 0 [unknown] => 5629a74892be main+0x0 20417.302513948: tr end call 5629a74892c6 main+0x8 => 5629a7489110 fn2@plt+0x0 20417.302513949: tr strt 0 [unknown] => 5629a74892cb main+0xd 20417.302513949: tr end call 5629a74892cb main+0xd => 5629a74890f0 fn3@plt+0x0 20417.302513950: tr strt 0 [unknown] => 5629a74892d0 main+0x12 20417.302513950: tr end call 5629a74892d0 main+0x12 => 5629a74890d0 __stack_chk_fail@plt+0x0 20417.302528114: tr strt 0 [unknown] => 5629a74892d5 main+0x17 20417.302528114: tr end call 5629a74892d5 main+0x17 => 5629a7489120 getrandom@plt+0x0 20417.302528115: tr strt 0 [unknown] => 5629a74892da main+0x1c 20417.302528115: tr end call 5629a74892da main+0x1c => 5629a7489100 fn4@plt+0x0 20417.302528115: tr strt 0 [unknown] => 5629a74892df main+0x21 20417.302528115: tr end return 5629a74892e5 main+0x27 => 7ff14da29d90 __libc_start_call_main+0x80 After: $ perf script --itrace=be --ns -F+flags,-event,+addr,-period,-comm,-tid,-cpu,-dso 20417.302513948: tr strt 0 [unknown] => 5629a74892be main+0x0 20417.302513948: tr end call 5629a74892c6 main+0x8 => 5629a7489110 fn4@plt+0x0 20417.302513949: tr strt 0 [unknown] => 5629a74892cb main+0xd 20417.302513949: tr end call 5629a74892cb main+0xd => 5629a74890f0 fn1@plt+0x0 20417.302513950: tr strt 0 [unknown] => 5629a74892d0 main+0x12 20417.302513950: tr end call 5629a74892d0 main+0x12 => 5629a74890d0 offset_0x10d0@plt+0x0 20417.302528114: tr strt 0 [unknown] => 5629a74892d5 main+0x17 20417.302528114: tr end call 5629a74892d5 main+0x17 => 5629a7489120 fn2@plt+0x0 20417.302528115: tr strt 0 [unknown] => 5629a74892da main+0x1c 20417.302528115: tr end call 5629a74892da main+0x1c => 5629a7489100 fn3@plt+0x0 20417.302528115: tr strt 0 [unknown] => 5629a74892df main+0x21 20417.302528115: tr end return 5629a74892e5 main+0x27 => 7ff14da29d90 __libc_start_call_main+0x80 Reviewed-by: -
Adrian Hunter authored
The section .plt.sec was originally added for MPX and was first called .plt.bnd. While MPX has been deprecated, .plt.sec is now also used for IBT. On x86_64, IBT may be enabled by default, but can be switched off using gcc option -fcf-protection=none, or switched on by -z ibt or -z ibtplt. On 32-bit, option -z ibt or -z ibtplt will enable IBT. With .plt.sec, calls are made into .plt.sec instead of .plt, so it makes more sense to put the symbols there instead of .plt. A notable difference is that .plt.sec does not have a header entry. For x86, when synthesizing symbols for plt, use offset and entry size of .plt.sec instead of .plt when there is a .plt.sec section. Example on Ubuntu 22.04 gcc 11.3: Before: $ cat tstpltlib.c void fn1(void) {} void fn2(void) {} void fn3(void) {} void fn4(void) {} $ cat tstplt.c void fn1(void); void fn2(void); void fn3(void); void fn4(void); int main() { fn4(); fn1(); fn2(); fn3(); return 0; } $ gcc --version gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -Wall -Wextra -shared -o libtstpltlib.so tstpltlib.c $ gcc -Wall -Wextra -z ibt -o tstplt tstplt.c -L . -ltstpltlib -Wl,-rpath=$(pwd) $ readelf -SW tstplt | grep 'plt\|Name' [Nr] Name Type Address Off Size ES Flg Lk Inf Al [11] .rela.plt RELA 0000000000000698 000698 000060 18 AI 6 24 8 [13] .plt PROGBITS 0000000000001020 001020 000050 10 AX 0 0 16 [14] .plt.got PROGBITS 0000000000001070 001070 000010 10 AX 0 0 16 [15] .plt.sec PROGBITS 0000000000001080 001080 000040 10 AX 0 0 16 $ perf record -e intel_pt//u --filter 'filter main @ ./tstplt' ./tstplt [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.015 MB perf.data ] $ perf script --itrace=be --ns -F+flags,-event,+addr,-period,-comm,-tid,-cpu,-dso 38970.522546686: tr strt 0 [unknown] => 55fc222a81a9 main+0x0 38970.522546686: tr end call 55fc222a81b1 main+0x8 => 55fc222a80a0 [unknown] 38970.522546687: tr strt 0 [unknown] => 55fc222a81b6 main+0xd 38970.522546687: tr end call 55fc222a81b6 main+0xd => 55fc222a8080 [unknown] 38970.522546688: tr strt 0 [unknown] => 55fc222a81bb main+0x12 38970.522546688: tr end call 55fc222a81bb main+0x12 => 55fc222a80b0 [unknown] 38970.522546688: tr strt 0 [unknown] => 55fc222a81c0 main+0x17 38970.522546688: tr end call 55fc222a81c0 main+0x17 => 55fc222a8090 [unknown] 38970.522546689: tr strt 0 [unknown] => 55fc222a81c5 main+0x1c 38970.522546894: tr end return 55fc222a81cb main+0x22 => 7f3a4dc29d90 __libc_start_call_main+0x80 After: $ perf script --itrace=be --ns -F+flags,-event,+addr,-period,-comm,-tid,-cpu,-dso 38970.522546686: tr strt 0 [unknown] => 55fc222a81a9 main+0x0 38970.522546686: tr end call 55fc222a81b1 main+0x8 => 55fc222a80a0 fn4@plt+0x0 38970.522546687: tr strt 0 [unknown] => 55fc222a81b6 main+0xd 38970.522546687: tr end call 55fc222a81b6 main+0xd => 55fc222a8080 fn1@plt+0x0 38970.522546688: tr strt 0 [unknown] => 55fc222a81bb main+0x12 38970.522546688: tr end call 55fc222a81bb main+0x12 => 55fc222a80b0 fn2@plt+0x0 38970.522546688: tr strt 0 [unknown] => 55fc222a81c0 main+0x17 38970.522546688: tr end call 55fc222a81c0 main+0x17 => 55fc222a8090 fn3@plt+0x0 38970.522546689: tr strt 0 [unknown] => 55fc222a81c5 main+0x1c 38970.522546894: tr end return 55fc222a81cb main+0x22 => 7f3a4dc29d90 __libc_start_call_main+0x80 Reviewed-by: -
Adrian Hunter authored
In 32-bit executables the .plt entry size can be set to 4 when it is really 16. In fact the only sizes used for x86 (32 or 64 bit) are 8 or 16, so check for those and, if not, use the alignment to choose which it is. Example on Ubuntu 22.04 gcc 11.3: Before: $ cat tstpltlib.c void fn1(void) {} void fn2(void) {} void fn3(void) {} void fn4(void) {} $ cat tstplt.c void fn1(void); void fn2(void); void fn3(void); void fn4(void); int main() { fn4(); fn1(); fn2(); fn3(); return 0; } $ gcc --version gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc -m32 -Wall -Wextra -shared -o libtstpltlib32.so tstpltlib.c $ gcc -m32 -Wall -Wextra -o tstplt32 tstplt.c -L . -ltstpltlib32 -Wl,-rpath=$(pwd) $ perf record -e intel_pt//u --filter 'filter main @ ./tstplt32' ./tstplt32 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.011 MB perf.data ] $ readelf -SW tstplt32 | grep 'plt\|Name' [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [10] .rel.plt REL 0000041c 00041c 000028 08 AI 5 22 4 [12] .plt PROGBITS 00001030 001030 000060 04 AX 0 0 16 <- ES is 0x04, should be 0x10 [13] .plt.got PROGBITS 00001090 001090 000008 08 AX 0 0 8 $ perf script --itrace=be --ns -F+flags,-event,+addr,-period,-comm,-tid,-cpu,-dso 17894.383903029: tr strt 0 [unknown] => 565b81cd main+0x0 17894.383903029: tr end call 565b81d4 main+0x7 => 565b80d0 __x86.get_pc_thunk.bx+0x0 17894.383903031: tr strt 0 [unknown] => 565b81d9 main+0xc 17894.383903031: tr end call 565b81df main+0x12 => 565b8070 [unknown] 17894.383903032: tr strt 0 [unknown] => 565b81e4 main+0x17 17894.383903032: tr end call 565b81e4 main+0x17 => 565b8050 [unknown] 17894.383903033: tr strt 0 [unknown] => 565b81e9 main+0x1c 17894.383903033: tr end call 565b81e9 main+0x1c => 565b8080 [unknown] 17894.383903033: tr strt 0 [unknown] => 565b81ee main+0x21 17894.383903033: tr end call 565b81ee main+0x21 => 565b8060 [unknown] 17894.383903237: tr strt 0 [unknown] => 565b81f3 main+0x26 17894.383903237: tr end return 565b81fc main+0x2f => f7c21519 [unknown] After: $ perf script --itrace=be --ns -F+flags,-event,+addr,-period,-comm,-tid,-cpu,-dso 17894.383903029: tr strt 0 [unknown] => 565b81cd main+0x0 17894.383903029: tr end call 565b81d4 main+0x7 => 565b80d0 __x86.get_pc_thunk.bx+0x0 17894.383903031: tr strt 0 [unknown] => 565b81d9 main+0xc 17894.383903031: tr end call 565b81df main+0x12 => 565b8070 fn4@plt+0x0 17894.383903032: tr strt 0 [unknown] => 565b81e4 main+0x17 17894.383903032: tr end call 565b81e4 main+0x17 => 565b8050 fn1@plt+0x0 17894.383903033: tr strt 0 [unknown] => 565b81e9 main+0x1c 17894.383903033: tr end call 565b81e9 main+0x1c => 565b8080 fn2@plt+0x0 17894.383903033: tr strt 0 [unknown] => 565b81ee main+0x21 17894.383903033: tr end call 565b81ee main+0x21 => 565b8060 fn3@plt+0x0 17894.383903237: tr strt 0 [unknown] => 565b81f3 main+0x26 17894.383903237: tr end return 565b81fc main+0x2f => f7c21519 [unknown] Reviewed-by: -
Athira Rajeev authored
Test “Use vfs_getname probe to get syscall args filenames” fails in environment with missing libtraceevent support as below: 82: Use vfs_getname probe to get syscall args filenames : --- start --- test child forked, pid 304726 Recording open file: event syntax error: 'probe:vfs_getname*' \___ unsupported tracepoint libtraceevent is necessary for tracepoint support Run 'perf list' for a list of valid events Usage: perf record [<options>] [<command>] or: perf record [<options>] -- <command> [<options>] -e, --event <event> event selector. use 'perf list' to list available events test child finished with -1 ---- end ---- Use vfs_getname probe to get syscall args filenames: FAILED! The environment has debuginfo but is missing the libtraceevent devel. Hence perf is compiled without libtraceevent support. The test tries to add probe “probe:vfs_getname” and then uses it with “perf record”. This fails at function “parse_events_add_tracepoint" due to missing libtraceevent. Similarly "probe libc's inet_pton & backtrace it with ping" test slso fails with same reason. Add a function in 'perf test shell' library to check if perf record with —dry-run reports any error on missing support for libtraceevent. Update both the tests to use this new function “skip_no_probe_record_support” before proceeding With using probe point via perf builtin record. With the change, 82: Use vfs_getname probe to get syscall args filenames : --- start --- test child forked, pid 305014 Recording open file: libtraceevent is necessary for tracepoint support test child finished with -2 ---- end ---- Use vfs_getname probe to get syscall args filenames: Skip 81: probe libc's inet_pton & backtrace it with ping : --- start --- test child forked, pid 305036 libtraceevent is necessary for tracepoint support test child finished with -2 ---- end ---- probe libc's inet_pton & backtrace it with ping: Skip Signed-off-by:Athira Rajeev <atrajeev@linux.vnet.ibm.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Disha Goel <disgoel@linux.ibm.com> Cc: Ian Rogers <irogers@google.com> Cc: James Clark <james.clark@arm.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Madhavan Srinivasan <maddy@linux.vnet.ibm.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nageswara R Sastry <rnsastry@linux.ibm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: kjain@linux.ibm.com, Cc: linuxppc-dev@lists.ozlabs.org Link: http://lore.kernel.org/r/20230201180421.59640-2-atrajeev@linux.vnet.ibm.comSigned-off-by:
-
Athira Rajeev authored
The "probe libc's inet_pton & backtrace it with ping" test installs a uprobe and uses perf record/script to check the backtrace. Currently even if the "perf record" fails, the test reports success. Logs below: # ./perf test -v "probe libc's inet_pton & backtrace it with ping" 81: probe libc's inet_pton & backtrace it with ping : --- start --- test child forked, pid 304211 failed to open /tmp/perf.data.Btf: No such file or directory test child finished with 0 ---- end ---- probe libc's inet_pton & backtrace it with ping: Ok Fix this by adding check for presence of perf.data file before proceeding with "perf script". With the patch changes, test reports fail correctly. # ./perf test -v "probe libc's inet_pton & backtrace it with ping" 81: probe libc's inet_pton & backtrace it with ping : --- start --- test child forked, pid 304358 FAIL: perf record failed to create "/tmp/perf.data.Uoi" test child finished with -1 ---- end ---- probe libc's inet_pton & backtrace it with ping: FAILED! Signed-off-by:
-
Namhyung Kim authored
The test_pipe() function will check perf report and perf inject with pipe input. Reviewed-by:
-
Namhyung Kim authored
We should not call lseek(2) for pipes as it won't work. And we already in the proper place to read the data for AUXTRACE. Add the comment like in the PERF_RECORD_HEADER_TRACING_DATA. Reviewed-by:
James Clark <james.clark@arm.com> Signed-off-by:
-
Namhyung Kim authored
When it processes AUXTRACE_INFO, it calls to auxtrace_queue_data() to collect AUXTRACE data first. That won't work with pipe since it needs lseek() to read the scattered aux data. $ perf record -o- -e intel_pt// true | perf report -i- --itrace=i100 # To display the perf.data header info, please use --header/--header-only options. # 0x4118 [0xa0]: failed to process type: 70 Error: failed to process sample For the pipe mode, it can handle the aux data as it gets. But there's no guarantee it can get the aux data in time. So the following warning will be shown at the beginning: WARNING: Intel PT with pipe mode is not recommended. The output cannot relied upon. In particular, time stamps and the order of events may be incorrect. Fixes: dbd13432 ("perf intel-pt: Add support for decoding AUX area samples") Reviewed-by:
-
- 01 Feb, 2023 1 commit
-
-
Namhyung Kim authored
In copy_bytes(), it reads the data from the (input) fd and writes it to the output file. But it does with the read(2) unconditionally which caused a problem of mixing buffered vs unbuffered I/O together. You can see the problem when using pipes. $ perf record -e intel_pt// -o- true | perf inject -b > /dev/null [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.000 MB - ] 0x45c0 [0x30]: failed to process type: 71 It should use perf_data__read() to honor the 'use_stdio' setting. Fixes: 60136667 ("perf data: Allow to use stdio functions for pipe mode") Reviewed-by:
-
- 30 Jan, 2023 2 commits
-
-
Mike Leach authored
OpenCSD version 1.4 is released with support for FEAT_ITE. This adds a new packet type, with associated output element ID in the packet type enum - OCSD_GEN_TRC_ELEM_INSTRUMENTATION. As we just ignore this packet in perf, add to the switch statement to avoid the "enum not handled in switch error", but conditionally so as not to break the perf build for older OpenCSD installations. Reviewed-by:
Mike Leach <mike.leach@linaro.org> Acked-by:
Ian Rogers <irogers@google.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Leo Yan <leo.yan@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Suzuki Poulouse <suzuki.poulose@arm.com> Cc: coresight@lists.linaro.org Cc: linux-arm-kernel@lists.infradead.org Link: https://lore.kernel.org/r/20230120153706.20388-1-mike.leach@linaro.orgSigned-off-by:
-
Naveen N. Rao authored
'DWARF unwind' 'perf test' can sometimes fail: $ perf test -v 74 Couldn't bump rlimit(MEMLOCK), failures may take place when creating BPF maps, etc 74: Test dwarf unwind : --- start --- test child forked, pid 3785254 Problems creating module maps, continuing anyway... Problems creating module maps, continuing anyway... unwind: test__arch_unwind_sample:ip = 0x102d0ad4c (0x36ad4c) unwind: access_mem addr 0x7fffc33128c8, val 1031c3228, offset 120 unwind: access_mem addr 0x7fffc33128d0, val 12427cc70, offset 128 <snip> unwind: test_dwarf_unwind__krava_3:ip = 0x102b8768b (0x1e768b) unwind: access_mem addr 0x7fffc3313048, val 7fffc3313050, offset 2040 unwind: access_mem addr 0x7fffc3313060, val 102b8777c, offset 2064 unwind: test_dwarf_unwind__krava_2:ip = 0x102b8770b (0x1e770b) unwind: access_mem addr 0x7fffc3313088, val 7fffc3313090, offset 2104 unwind: access_mem addr 0x7fffc33130a0, val 102b87890, offset 2128 unwind: test_dwarf_unwind__krava_1:ip = 0x102b8777b (0x1e777b) unwind: access_mem addr 0x7fffc3313108, val 10323a274, offset 2232 unwind: access_mem addr 0x7fffc3313110, val ffffffffffffffff, offset 2240 unwind: access_mem addr 0x7fffc3313118, val 102c08ed0, offset 2248 unwind: access_mem addr 0x7fffc3313120, val 1031db000, offset 2256 unwind: access_mem addr 0x7fffc3313128, val 7fffc3313130, offset 2264 unwind: access_mem addr 0x7fffc3313140, val 102b45ee8, offset 2288 unwind: '':ip = 0x102b8788f (0x1e788f) failed: got unresolved address 0x102b8788f unwind: failed with 'no error' got wrong number of stack entries 0 != 8 test child finished with -1 ---- end ---- Test dwarf unwind: FAILED! We expect to resolve test__dwarf_unwind as the last symbol, but that function can be optimized away: $ objdump -tT /usr/bin/perf | grep dwarf_unwind 000000000083b018 g DO .data 0000000000000040 Base tests__dwarf_unwind 00000000001e7750 g DF .text 0000000000000068 Base 0x60 test_dwarf_unwind__krava_1 00000000001e76e0 g DF .text 0000000000000068 Base 0x60 test_dwarf_unwind__krava_2 00000000001e7620 g DF .text 00000000000000b4 Base 0x60 test_dwarf_unwind__krava_3 00000000001e74f0 g DF .text 0000000000000128 Base 0x60 test_dwarf_unwind__compare 00000000001e7350 g DF .text 000000000000019c Base 0x60 test_dwarf_unwind__thread 000000000083b000 g DO .data 0000000000000018 Base suite__dwarf_unwind Fix this similar to commit fdf7c49c ("perf tests: Fix dwarf unwind for stripped binaries") by marking the function as a global and adding the 'noinline' attribute to it. With this patch: $ objdump -tT perf | grep dwarf_unwind 000000000083b018 g DO .data 0000000000000040 Base tests__dwarf_unwind 00000000001e80f0 g DF .text 0000000000000068 Base 0x60 test_dwarf_unwind__krava_1 00000000001e8080 g DF .text 0000000000000068 Base 0x60 test_dwarf_unwind__krava_2 00000000001e7fc0 g DF .text 00000000000000b4 Base 0x60 test_dwarf_unwind__krava_3 00000000001e7e90 g DF .text 0000000000000128 Base 0x60 test_dwarf_unwind__compare 00000000001e7cf0 g DF .text 000000000000019c Base 0x60 test_dwarf_unwind__thread 00000000001e8160 g DF .text 0000000000000248 Base 0x60 test__dwarf_unwind 000000000083b000 g DO .data 0000000000000018 Base suite__dwarf_unwind $ ./perf test 74 74: Test dwarf unwind : Ok Reported-by:
Disha Goel <disgoel@linux.vnet.ibm.com> Signed-off-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Link: http://lore.kernel.org/lkml/20230125123442.107156-1-naveen.n.rao@linux.vnet.ibm.comSigned-off-by:
-
- 27 Jan, 2023 4 commits
-
-
Ian Rogers authored
build_id__init() only copies the buildid data up to size leaving the rest of the data array uninitialized. Copying the full array during synthesis means the written event contains uninitialized memory. Ensure the size is less that the buffer size and only copy the bytes that were initialized. This was detected by the Clang/LLVM memory sanitizer. v2. Avoids the potential for copying too much as suggested by Arnaldo. Suggested-by:
-
James Clark authored
Setup is non-trivial so also link to the full SPE docs. Signed-off-by:
-
James Clark authored
Make the sink error message more similar to the event error message that reminds about missing kernel support. The available sinks are also determined by the hardware so mention that too. Also, usually it's not necessary to specify the sink, so add that as a hint. Now the error for a made up sink looks like this: $ perf record -e cs_etm/@abc/ Couldn't find sink "abc" on event cs_etm/@abc/. Missing kernel or device support? Hint: An appropriate sink will be picked automatically if one isn't is specified. For any error other than ENOENT, the same message as before is displayed. Signed-off-by:
Suzuki Poulouse <suzuki.poulose@arm.com> Suggested-by:
-
Arnaldo Carvalho de Melo authored
Ian has been reviewing perf tooling patches consistently for a long time, so lets reflect that in the MAINTAINERS file so that contributors add him to the CC list in patch submissions. Reviewed-by:
Ingo Molnar <mingo@kernel.org> Acked-by:
Jiri Olsa <jolsa@kernel.org> Acked-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
-
- 23 Jan, 2023 4 commits
-
-
Athira Rajeev authored
The perf test named “build id cache operations” skips with below error on some distros: <<>> 78: build id cache operations : test child forked, pid 111101 WARNING: wine not found. PE binaries will not be run. test binaries: /tmp/perf.ex.SHA1.PKz /tmp/perf.ex.MD5.Gt3 ./tests/shell/../pe-file.exe DEBUGINFOD_URLS= Adding 4abd406f041feb4f10ecde3fc30fd0639e1a91cb /tmp/perf.ex.SHA1.PKz: Ok build id: 4abd406f041feb4f10ecde3fc30fd0639e1a91cb ./tests/shell/buildid.sh: 69: ./tests/shell/buildid.sh: Bad substitution test child finished with -2 build id cache operations: Skip <<>> The test script "tests/shell/buildid.sh" uses some of the string substitution ways which are supported in bash, but not in "sh" or other shells. Above error on line number 69 that reports "Bad substitution" is: <<>> link=${build_id_dir}/.build-id/${id:0:2}/${id:2} <<>> Here the way of getting first two characters from id ie, ${id:0:2} and similarly expressions like ${id:2} is not recognised in "sh". So the line errors and instead of hitting failure, the test gets skipped as shown in logs. So the syntax issue causes test not to be executed in such cases. Similarly usage : "${@: -1}" [ to pick last argument passed to a function] in “test_record” doesn’t work in all distros. Fix this by using alternative way with shell substitution to pick required characters from the string. Also fix the usage of “${@: -1}” to work in all cases. Another usage in “test_record” is: <<>> ${perf} record --buildid-all -o ${data} $@ &> ${log} <<>> This causes the 'perf record' to start in background and Results in the data file not being created by the time "check" function is invoked. Below log shows 'perf record' result getting displayed after the call to "check" function. <<>> running: perf record /tmp/perf.ex.SHA1.EAU build id: 4abd406f041feb4f10ecde3fc30fd0639e1a91cb link: /tmp/perf.debug.mLT/.build-id/4a/bd406f041feb4f10ecde3fc30fd0639e1a91cb failed: link /tmp/perf.debug.mLT/.build-id/4a/bd406f041feb4f10ecde3fc30fd0639e1a91cb does not exist test child finished with -1 build id cache operations: FAILED! root@machine:~/athira/linux/tools/perf# Couldn't synthesize bpf events. [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.010 MB /tmp/perf.data.bFF ] <<>> Fix this by redirecting output instead of using “&” which starts the command in background. Reviewed-by:David Laight <David.Laight@ACULAB.COM> Signed-off-by:
Disha Goel <disgoel@linux.ibm.com> Acked-by:
-
Diederik de Haas authored
Fix various spelling errors as reported by Debian's lintian tool. "amount of times" -> "number of times" ocurrence -> occurrence upto -> up to Signed-off-by:
Diederik de Haas <didi.debian@cknow.org> Acked-by:
-
Naveen N. Rao authored
BPF filtering tests can sometime fail. Running the test in verbose mode shows the following: $ sudo perf test 42 42: BPF filter : 42.1: Basic BPF filtering : FAILED! 42.2: BPF pinning : Skip 42.3: BPF prologue generation : Skip $ perf --version perf version 4.18.0-425.3.1.el8.ppc64le $ sudo perf test -v 42 42: BPF filter : 42.1: Basic BPF filtering : --- start --- test child forked, pid 711060 ... bpf: config 'func=do_epoll_wait' is ok Looking at the vmlinux_path (8 entries long) Using /usr/lib/debug/lib/modules/4.18.0-425.3.1.el8.ppc64le/vmlinux for symbols Open Debuginfo file: /usr/lib/debug/.build-id/81/56f5a07f92ccb62c5600ba0e4aacfb5f3a7534.debug Try to find probe point from debuginfo. Matched function: do_epoll_wait [4ef8cb0] found inline addr: 0xc00000000061dbe4 Probe point found: __se_compat_sys_epoll_pwait+196 found inline addr: 0xc00000000061d9f4 Probe point found: __se_sys_epoll_pwait+196 found inline addr: 0xc00000000061d824 Probe point found: __se_sys_epoll_wait+36 Found 3 probe_trace_events. Opening /sys/kernel/tracing//kprobe_events write=1 ... BPF filter result incorrect, expected 56, got 56 samples test child finished with -1 ---- end ---- BPF filter subtest 1: FAILED! The statement above about the result being incorrect looks weird, and it is due to that particular perf build missing commit 3e11300c ("perf test: Fix bpf test sample mismatch reporting"). In reality, due to commit 4b04e0de ("perf test: Fix basic bpf filtering test"), perf expects there to be 56*3 samples. However, the number of samples we receive is going to be dependent on where the probes are installed, which is dependent on where do_epoll_wait gets inlined. On s390x, it looks like probes at all the inlined locations are hit. But, that is not the case on ppc64le. Fix this by switching the test to instead use the syscall tracepoint. This ensures that we will only ever install a single event enabling us to reliably determine the sample count. Reported-by:
-
Arnaldo Carvalho de Melo authored
To pick fixes that went via perf/urgent. Signed-off-by:
-
- 22 Jan, 2023 19 commits
-
-
James Clark authored
There are some edge cases around estimated timestamps that can result in them going backwards. One is that after a discontinuity, the last used timestamp is set to 0. The duration of the next range is then subtracted which could result in an earlier timestamp than the last instruction. Fix this by not resetting the last timestamp used on a discontinuity, and make sure that new estimated timestamps are clamped to be later than that. Another case is that estimated timestamps could compound over time to end up being more than the next real timestamp in the trace. Fix this by clamping the estimates in cs_etm_decoder__do_soft_timestamp() to be no later than it. cs_etm_decoder__do_soft_timestamp() also updated next_cs_timestamp, which meant that the next real timestamp was lost and not stored anywhere. Fix that by only updating cs_timestamp for estimates and keep next_cs_timestamp untouched. Finally, use next_cs_timestamp to signify if a timestamp has been received previously. Because cs_timestamp has the first range subtracted, it could technically go to 0 which would break the logic. Testing ======= It can be verified that timestamps don't go backwards when tracing on a single core with the following commands. Across multiple cores it's expected that timestamps are interleaved: $ perf record -e cs_etm/@tmc_etr0/k -C 4 taskset -c 4 sleep 1 $ perf script --itrace=i1ns --ns -Fcomm,tid,pid,time,cpu,event,ip,sym,addr,symoff,flags,callindent > itrace $ sed 's/://g' itrace | awk -F ' ' ' { print $4 } ' | awk '{ if ($1 < prev) { print "line:" NR " " $0 } {prev=$1}}' Reported-by:Tanmay Jagdale <tanmay@marvell.com> Signed-off-by:
-
German Gomez authored
If virtual timestamps are detected, set sample time field accordingly, otherwise warn the user that the samples will not include accurate time data. | Test notes (FEAT_TRF platform) | | $ ./perf record -e cs_etm//u -a -- sleep 4 | $ ./perf script --fields +time | perf 422 [000] 163.375100: 1 branches:uH: 0 [unknown] ([unknown]) | perf 422 [000] 163.375100: 1 branches:uH: ffffb8009544 ioctl+0x14 (/lib/aarch64-linux-gnu/libc-2.27.so) | perf 422 [000] 163.375100: 1 branches:uH: aaaaab6bebf4 perf_evsel__run_ioctl+0x90 (/home/german/linux/tools/perf/perf) | [...] | perf 422 [000] 167.393100: 1 branches:uH: aaaaab6bda00 __xyarray__entry+0x74 (/home/german/linux/tools/perf/perf) | perf 422 [000] 167.393099: 1 branches:uH: aaaaab6bda0c __xyarray__entry+0x80 (/home/german/linux/tools/perf/perf) | perf 422 [000] 167.393099: 1 branches:uH: ffffb8009538 ioctl+0x8 (/lib/aarch64-linux-gnu/libc-2.27.so) | | The time from the first sample to the last sample is 4 seconds Now that times are converted to nanoseconds, also try to estimate the timestamps more accurately be dividing by some fixed value for instructions per ns. This prevents long ranges from being estimated too far in the past than would be realistic. Signed-off-by:
German Gomez <german.gomez@arm.com> Acked-by:
-
German Gomez authored
Read the value of ts_source exposed by the driver and store it in the ETMv4 and ETE header. If the interface doesn't exist (such as in older Kernels), defaults to a safe value of -1. Signed-off-by:
-
German Gomez authored
Previously, adding a new parameter at the end of ETMv4 meant adding it somewhere in the middle of ETE, which is not supported by the current header version. Reviewed-by:
-
German Gomez authored
Add a utility function perf_pmu__file_exists() to check if a given pmu file exists in the sysfs filesystem. Signed-off-by:
-
James Clark authored
Use the new perf_pmu__pathname_scnprintf() instead. No functional changes. Reviewed-by:
Leo Yan <leo.yan@linaro.org> Signed-off-by:
-
James Clark authored
Remove some code that duplicates existing methods. Copy strings where const strings are required. No functional changes. Committer notes: Add a stub for erf_pmu__scan_file() in tools/perf/util/python.c not to drag tools/perf/util/pmu.c into the python binding. This fixes 'perf test python' at this point in this patchset. Reviewed-by:
-
James Clark authored
The pattern for accessing EVENT_SOURCE_DEVICE_PATH is duplicated in a few places, so add two utility functions to cover it. Also just use perf_pmu__scan_file() instead of pmu_type() which already does the same thing. No functional changes. Reviewed-by:
-
Ian Rogers authored
In the context of LBR stitching documentation. Signed-off-by:
Kan Liang <kan.liang@linux.intel.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ali Saidi <alisaidi@amazon.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Clark <james.clark@arm.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Leo Yan <leo.yan@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ravi Bangoria <ravi.bangoria@amd.com> Cc: Sandipan Das <sandipan.das@amd.com> Link: https://lore.kernel.org/r/20230119201036.156441-1-irogers@google.comSigned-off-by:
-
Adrian Hunter authored
Make the code more readable by checking for SHT_RELA and SHT_REL type earlier. Signed-off-by:
-
Adrian Hunter authored
SHT_REL and SHT_RELA are handled the same way. Simplify by combining the handling. Signed-off-by:
-
Adrian Hunter authored
Create a sensible name for .plt entries with no symbol. Example: Before: $ perf test --dso /usr/lib/x86_64-linux-gnu/libc.so.6 -vv Symbols 2>/tmp/cmp1.txt After: $ perf test --dso /usr/lib/x86_64-linux-gnu/libc.so.6 -vv Symbols 2>/tmp/cmp2.txt $ diff /tmp/cmp1.txt /tmp/cmp2.txt 4c4 < test child forked, pid 53043 --- > test child forked, pid 54372 23,62c23,62 < 280f0-28100 g @plt < 28100-28110 g @plt < 28110-28120 g @plt < 28120-28130 g @plt < 28130-28140 g @plt < 28140-28150 g @plt < 28150-28160 g @plt < 28160-28170 g @plt < 28170-28180 g @plt < 28180-28190 g @plt < 28190-281a0 g @plt < 281a0-281b0 g @plt < 281b0-281c0 g @plt < 281c0-281d0 g @plt < 281d0-281e0 g @plt < 281e0-281f0 g @plt < 281f0-28200 g @plt < 28200-28210 g @plt < 28210-28220 g @plt < 28220-28230 g @plt < 28230-28240 g @plt < 28240-28250 g @plt < 28250-28260 g @plt < 28260-28270 g @plt < 28270-28280 g @plt < 28280-28290 g @plt < 28290-282a0 g @plt < 282a0-282b0 g @plt < 282b0-282c0 g @plt < 282c0-282d0 g @plt < 282d0-282e0 g @plt < 282e0-282f0 g @plt < 282f0-28300 g @plt < 28300-28310 g @plt < 28310-28320 g @plt < 28320-28330 g @plt < 28330-28340 g @plt < 28340-28350 g @plt < 28350-28360 g @plt < 28360-28370 g @plt --- > 280f0-28100 g offset_0x280f0@plt > 28100-28110 g offset_0x28100@plt > 28110-28120 g offset_0x28110@plt > 28120-28130 g offset_0x28120@plt > 28130-28140 g offset_0x28130@plt > 28140-28150 g offset_0x28140@plt > 28150-28160 g offset_0x28150@plt > 28160-28170 g offset_0x28160@plt > 28170-28180 g offset_0x28170@plt > 28180-28190 g offset_0x28180@plt > 28190-281a0 g offset_0x28190@plt > 281a0-281b0 g offset_0x281a0@plt > 281b0-281c0 g offset_0x281b0@plt > 281c0-281d0 g offset_0x281c0@plt > 281d0-281e0 g offset_0x281d0@plt > 281e0-281f0 g offset_0x281e0@plt > 281f0-28200 g offset_0x281f0@plt > 28200-28210 g offset_0x28200@plt > 28210-28220 g offset_0x28210@plt > 28220-28230 g offset_0x28220@plt > 28230-28240 g offset_0x28230@plt > 28240-28250 g offset_0x28240@plt > 28250-28260 g offset_0x28250@plt > 28260-28270 g offset_0x28260@plt > 28270-28280 g offset_0x28270@plt > 28280-28290 g offset_0x28280@plt > 28290-282a0 g offset_0x28290@plt > 282a0-282b0 g offset_0x282a0@plt > 282b0-282c0 g offset_0x282b0@plt > 282c0-282d0 g offset_0x282c0@plt > 282d0-282e0 g offset_0x282d0@plt > 282e0-282f0 g offset_0x282e0@plt > 282f0-28300 g offset_0x282f0@plt > 28300-28310 g offset_0x28300@plt > 28310-28320 g offset_0x28310@plt > 28320-28330 g offset_0x28320@plt > 28330-28340 g offset_0x28330@plt > 28340-28350 g offset_0x28340@plt > 28350-28360 g offset_0x28350@plt > 28360-28370 g offset_0x28360@plt Signed-off-by: -
Adrian Hunter authored
perf expands the _init symbol over .plt because there are no PLT symbols at that point, but then dso__synthesize_plt_symbols() creates them. Fix by truncating the previous symbol and inserting a symbol for .plt header. Example: Before: $ perf test --dso `which uname` -v Symbols 74: Symbols : --- start --- test child forked, pid 191028 Problems creating module maps, continuing anyway... Testing /usr/bin/uname Overlapping symbols: 2000-25f0 g _init 2040-2050 g free@plt test child finished with -1 ---- end ---- Symbols: FAILED! $ perf test --dso `which uname` -vv Symbols 2>/tmp/cmp1.txt After: $ perf test --dso `which uname` -v Symbols 74: Symbols : --- start --- test child forked, pid 194291 Testing /usr/bin/uname test child finished with 0 ---- end ---- Symbols: Ok $ perf test --dso `which uname` -vv Symbols 2>/tmp/cmp2.txt $ diff /tmp/cmp1.txt /tmp/cmp2.txt 4,5c4 < test child forked, pid 191031 < Problems creating module maps, continuing anyway... --- > test child forked, pid 194296 9c8,9 < 2000-25f0 g _init --- > 2000-2030 g _init > 2030-2040 g .plt 100,103c100 < Overlapping symbols: < 2000-25f0 g _init < 2040-2050 g free@plt < test child finished with -1 --- > test child finished with 0 105c102 < Symbols: FAILED! --- > Symbols: Ok $ Signed-off-by: -
Adrian Hunter authored
ss->dynsym is checked to be not NULL twice. Remove the first check because, in fact, there can be a plt with no dynsym, which is something that will be dealt with later. Signed-off-by:
-
Adrian Hunter authored
Return zero directly instead of needless 'goto out_elf_end' that does the same thing. That allows 'err' to be initialized to -1 instead of having to change its value later. Signed-off-by:
-
Adrian Hunter authored
Symbols should not be cached when there are more symbols still to add. Add dso__find_symbol_nocache() to facilitate that. Signed-off-by:
-
Adrian Hunter authored
The code expects non-zero plt_entry_size. Check it and add a debug message to print if it is zero. Signed-off-by:
-
Adrian Hunter authored
Factor out get_plt_sizes() to make the code more readable and further changes to dso__synthesize_plt_symbols() easier to follow. Signed-off-by:
-
Adrian Hunter authored
Add a test to check function symbols do not overlap and are not zero length. The main motivation for the test is to make it easier to review changes to PLT symbol synthesis i.e. changes to dso__synthesize_plt_symbols(). By default the test uses the perf executable as a test DSO, but a specific DSO can be specified via a new perf test option "--dso". The test is useful in the following ways: - Any DSO can be tested, even ones that do not run on the current architecture. For example, using cross-compiled DSOs to see how well perf handles different architectures. - With verbose > 1 (e.g. -vv), all the symbols are printed, which makes it easier to see issues. - perf removes duplicate symbols and expands zero-length symbols to reach the next symbol, however that is done before adding synthesized symbols, so the test is checking those also. Example: $ perf test -v Symbols 74: Symbols : --- start --- test child forked, pid 154918 Testing /home/user/bin/perf Overlapping symbols: 7d000-7f3a0 g _init 7d030-7d040 g __printf_chk@plt test child finished with -1 ---- end ---- Symbols: FAILED! Note the test fails because perf expands the _init symbol over the PLT because there are no PLT symbols at that point, but then dso__synthesize_plt_symbols() creates them. Signed-off-by:
-
