aboutsummaryrefslogtreecommitdiff
path: root/gdb/python/py-breakpoint.c
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2024-09-21 05:55:18 +0200
committerTom de Vries <tdevries@suse.de>2024-09-21 05:55:18 +0200
commitf121b8cf753a7890ceb6533393e8fd242445e27d (patch)
tree6350b119e734674e28a1bb3bd35e6bf6f9f37aec /gdb/python/py-breakpoint.c
parentdfc2e69ba4a56fea8d748acba5f2b0069ad82618 (diff)
downloadbinutils-f121b8cf753a7890ceb6533393e8fd242445e27d.zip
binutils-f121b8cf753a7890ceb6533393e8fd242445e27d.tar.gz
binutils-f121b8cf753a7890ceb6533393e8fd242445e27d.tar.bz2
[gdb/testsuite] Drop -readnow in three gdb.dwarf2 test-cases
When running the testsuite in an enviroment simulating a stressed system, I ran into timeouts in three test-cases in gdb.dwarf2: - gdb.dwarf2/count.exp, - gdb.dwarf2/implptrconst.exp, and - gdb.dwarf2/implptrpiece.exp. In all three cases, -readnow is used which results in symtabs being expanded for the executable, /lib64/libc.so.6 and /lib64/ld-linux-x86-64.so.2. We could address this by limiting the scope of -readnow to the executable, but after reviewing the test-cases there doesn't seem to be a clear reason to use -readnow. Fix this by dropping the -readnow. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
Diffstat (limited to 'gdb/python/py-breakpoint.c')
0 files changed, 0 insertions, 0 deletions