]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
[gdb/testsuite] Fix gdb.base/backtrace-through-cu-nodebug.exp without python support
authorTom de Vries <tdevries@suse.de>
Sat, 19 Jul 2025 15:08:44 +0000 (17:08 +0200)
committerTom de Vries <tdevries@suse.de>
Sat, 19 Jul 2025 15:08:44 +0000 (17:08 +0200)
commit6ca57d1619172ff388bcd96341c999caebdfe344
tree1192cb9ecf227b402a229d42445dd70f68a2f676
parentd60ae6437b59d638c9b60c544b8943d413bbb1c3
[gdb/testsuite] Fix gdb.base/backtrace-through-cu-nodebug.exp without python support

With a gdb build without python support, and test-case
gdb.base/backtrace-through-cu-nodebug.exp I run into:
...
(gdb) bt^M
Required frame unwinder may have been disabled, \
  see 'maint info frame-unwinders'^M
(gdb) FAIL: $exp: verify unwind fail without CFI
...

With a gdb build with python support we have instead:
...
(gdb) bt^M
Python Exception <class 'gdb.error'>: \
  Required frame unwinder may have been disabled, \
  see 'maint info frame-unwinders'^M
(gdb) PASS: $exp: verify unwind fail without CFI
...
but if I change the "bt" into "bt -no-filters" I get the same FAIL and
corresponding output.

So there are two scenarios here.

In the first:
- the bt command is called
- frame #0 is printed
- trying to get the next frame fails and an error is thrown, aborting the
  backtrace
- the error is caught and printed

In the second:
- the bt command is called
- the frame filter is applied
- doing so triggers the same error, which is caught and printed by
  gdbpy_apply_frame_filter, returning EXT_LANG_BT_NO_FILTERS
- frame #0 is printed
- getting the next frame fails, and the backtrace stops

It seems worthwhile to exercise both scenarios if possible, so add a
"bt -no-filters" test.

Fix the FAIL by updating the regexp to allow both scenarios.

Tested on aarch64-linux.

Reviewed-By: Keith Seitz <keiths@redhat.com>
gdb/testsuite/gdb.base/backtrace-through-cu-nodebug.exp