I got a new laptop, build gdb and ran the gdb testsuite, and ran into: ... (gdb) PASS: gdb.btrace/exception.exp: continue to breakpoint: cont to bp.2 gdb_expect_list pattern: /1 main\(\)^M 2 test\(\)^M 3 foo\(\)^M 4 bar\(\)^M 5 bad\(\)^M/ record function-call-history 1^M 1 main()^M (gdb) FAIL: gdb.btrace/exception.exp: flat (pattern 1) ... I could reproduce it sometimes, but not all the time, till I tried out using taskset. When using: - taskset -c 0-3, the test-case passes. - taskset -c 4-11, the test-case fails. The processor is a i7-1250U with 12 threads: - 2 performance cores (I guess providing 2 threads per core), and - 8 efficient cores. So, I guess somehow it doesn't run properly on efficient cores.
Likewise for gdb.btrace/non-stop.exp
This is without libipt: ... configure:25703: checking for libipt configure:25722: gcc -o conftest -O0 -g -O0 -g -Wall conftest.c -lncursesw -lm -ldl -lipt >&5 conftest.c:178:10: fatal error: intel-pt.h: No such file or directory ... configure:25732: result: no configure:25759: WARNING: libipt is missing or unusable; some features may be unavailable. ... With libipt (using latest release v2.0.5) the two test-cases pass.
https://sourceware.org/pipermail/gdb-patches/2023-February/197036.html
(In reply to Tom de Vries from comment #3) > https://sourceware.org/pipermail/gdb-patches/2023-February/197036.html As per this reply ( https://sourceware.org/pipermail/gdb-patches/2023-February/197039.html ), this issue is different from PR30075, and is currently being investigated.
On my system, I do not get any BTS records on E-cores, and the perf event head pointer does not move. Looks like the BTS enable request gets stuck. Could you print the result of 'maint btrace packet-history 0, +100'?
(In reply to Markus Metzger from comment #5) > On my system, I do not get any BTS records on E-cores, and the perf event > head pointer does not move. Looks like the BTS enable request gets stuck. > > Could you print the result of 'maint btrace packet-history 0, +100'? I've build without libipt, ran the test-case gdb.btrace/exception.exp, copied outputs/gdb.btrace/exception/gdb.in.2 to gdb.in, edited it like so: ... $ cat gdb.in set height 0 set width 0 dir dir /data/vries/gdb/src/gdb/testsuite/gdb.btrace file /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.btrace/exception/exception delete breakpoints info breakpoints break -qualified main run set record function-call-history-size 0 break 56 break 59 continue set record btrace bts buffer-size 128000 record btrace continue maint btrace packet-history 0, +100 #record function-call-history 1 #record function-call-history /c 1 ... and ran it: ... $ gdb -q -batch -ex "set trace-commands on" -x gdb.in +set height 0 +set width 0 +dir +dir /data/vries/gdb/src/gdb/testsuite/gdb.btrace +file /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.btrace/exception/exception +delete breakpoints +info breakpoints No breakpoints or watchpoints. +break -qualified main Breakpoint 1 at 0x400768: file /data/vries/gdb/src/gdb/testsuite/gdb.btrace/exception.cc, line 55. +run Breakpoint 1, main () at /data/vries/gdb/src/gdb/testsuite/gdb.btrace/exception.cc:55 55 test (); +set record function-call-history-size 0 +break 56 Breakpoint 2 at 0x40076d: file /data/vries/gdb/src/gdb/testsuite/gdb.btrace/exception.cc, line 56. +break 59 Breakpoint 3 at 0x400779: file /data/vries/gdb/src/gdb/testsuite/gdb.btrace/exception.cc, line 59. +continue Breakpoint 2, main () at /data/vries/gdb/src/gdb/testsuite/gdb.btrace/exception.cc:56 56 test (); /* bp.1 */ +set record btrace bts buffer-size 128000 +record btrace +target record-btrace +target record-btrace +continue Breakpoint 3, main () at /data/vries/gdb/src/gdb/testsuite/gdb.btrace/exception.cc:59 59 return ret; /* bp.2 */ +maint btrace packet-history 0, +100 No trace. ... I hope that answers your question.
(In reply to Tom de Vries from comment #6) > record btrace > continue > maint btrace packet-history 0, +100 > #record function-call-history 1 > #record function-call-history /c 1 The maintenance command doesn't fetch the trace itself. We'd need some other record command before it, e.g. 'info record' or one of the two commented-out commands.
(In reply to Markus Metzger from comment #7) > (In reply to Tom de Vries from comment #6) > > > record btrace > > continue > > maint btrace packet-history 0, +100 > > #record function-call-history 1 > > #record function-call-history /c 1 > > The maintenance command doesn't fetch the trace itself. We'd need some > other record command before it, e.g. 'info record' or one of the two > commented-out commands. With the two commented out commands added back, I have: ... +continue Breakpoint 3, main () at /data/vries/gdb/src/gdb/testsuite/gdb.btrace/exception.cc:59 59 return ret; /* bp.2 */ +record function-call-history 1 1 main() +record function-call-history /c 1 1 main() +maint btrace packet-history 0, +100 0 begin: 0x40076d, end: 0x400779 ...
(In reply to Tom de Vries from comment #8) > (In reply to Markus Metzger from comment #7) > > (In reply to Tom de Vries from comment #6) > > > > > record btrace > > > continue > > > maint btrace packet-history 0, +100 > > > #record function-call-history 1 > > > #record function-call-history /c 1 > > > > The maintenance command doesn't fetch the trace itself. We'd need some > > other record command before it, e.g. 'info record' or one of the two > > commented-out commands. > > With the two commented out commands added back, I have: > ... > +continue > > Breakpoint 3, main () at > /data/vries/gdb/src/gdb/testsuite/gdb.btrace/exception.cc:59 > 59 return ret; /* bp.2 */ > +record function-call-history 1 > 1 main() > +record function-call-history /c 1 > 1 main() > +maint btrace packet-history 0, +100 > 0 begin: 0x40076d, end: 0x400779 > ... Thanks. Looks like you're not getting any BTS records, either. The one entry is the artificial record GDB adds to reach the current PC. It looks like a kernel issue to me. I'm discussing it with Intel kernel developers. This might take a bit of time.
(In reply to Markus Metzger from comment #9) > It looks like a kernel issue to me. I'm discussing it with Intel kernel > developers. This might take a bit of time. Ack. FTR, I'm running into this with: - openSUSE Leap 15.4 using kernel version 5.14.21, and - openSUSE Tumbleweed using kernel version 6.1.10.