aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/py-finishbreakpoint.c
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2024-10-26 14:48:44 +0200
committerTom de Vries <tdevries@suse.de>2024-10-26 14:48:44 +0200
commit4be75f1fad57427dae2e052cb8f5188ae995d750 (patch)
tree6c38a5b09ccd0417ca2b099f555b55cee0c6789c /gdb/python/py-finishbreakpoint.c
parent2bba46058789196c1c384896933cbc9692ef4933 (diff)
downloadgdb-4be75f1fad57427dae2e052cb8f5188ae995d750.zip
gdb-4be75f1fad57427dae2e052cb8f5188ae995d750.tar.gz
gdb-4be75f1fad57427dae2e052cb8f5188ae995d750.tar.bz2
[gdb/testsuite] Fix gdb.dwarf2/dwp-symlink.exp with target board fission-dwp
There are two test-cases that only run when the target board produces .dwp files, gdb.dwarf2/dwp-sepdebug.exp and gdb.dwarf2/dwp-symlink.exp. When running those test-cases with target board fission-dwp, I run into: ... (gdb) ptype main^M warning: Could not find DWO CU dwp-symlink0.dwo(0x496f1a7405c37a61) \ referenced by CU at offset 0xa6 [in module dwp-symlink]^M type = <unknown return type> ()^M (gdb) FAIL: gdb.dwarf2/dwp-symlink.exp: binary default, dwp at symlink ... coming from: ... # This case cannot work. gdb_test "ptype main" {type = int \(\)} "binary default, dwp at symlink" ... I had a bit of difficulty understanding what the test-case does/tries to do, so to build some understanding I reproduced the behaviour outside of the test-case: ... $ cat start.c void _start (void) {} $ gcc -gsplit-dwarf start.c -nostdlib $ gdb -q -batch a.out -ex "print _start" $1 = {void (void)} 0x400144 <_start> $ dwp -e a.out $ rm start.dwo $ gdb -q -batch a.out -ex "print _start" $1 = {void (void)} 0x400144 <_start> $ ln -s a.out b.out $ gdb -q -batch b.out -ex "print _start" $1 = {void (void)} 0x400144 <_start> $ mv a.out.dwp b.out.dwp $ gdb -q -batch b.out -ex "print _start" $1 = {void (void)} 0x400144 <_start> $ gdb -q -batch a.out -ex "print _start" During symbol reading: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \ referenced by CU at offset 0x0 [in module a.out] warning: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \ referenced by CU at offset 0x0 [in module a.out] $1 = {<text variable, no debug info>} 0x400144 <_start> ... and agreed, that cannot work: the DWO CU required in a.out is in b.out.dwp, and there's no way to find b.out.dwp starting from a.out. The fact that a FAIL is produced is incorrect, gdb does nothing wrong. Fix this by checking for the warning text instead. While we're at it, fix this PATH as well: ... (gdb) cd /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink^M Working directory /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink.^M (gdb) PASS: gdb.dwarf2/dwp-symlink.exp: cd \ /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink PATH: gdb.dwarf2/dwp-symlink.exp: cd \ /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink ... While we're at it, use string_to_regexp to simplify the test-case. Tested on x86_64-linux, with target board fission-dwp.
Diffstat (limited to 'gdb/python/py-finishbreakpoint.c')
0 files changed, 0 insertions, 0 deletions