* [PATCH] [gdb/testsuite] Fix timeouts in gdb.base/tls-dlobj.exp
@ 2026-01-07 9:19 Tom de Vries
2026-01-09 4:00 ` Kevin Buettner
0 siblings, 1 reply; 5+ messages in thread
From: Tom de Vries @ 2026-01-07 9:19 UTC (permalink / raw)
To: gdb-patches
When running the testsuite on a busy system, occasionally I run into timeouts in
test-case gdb.base/tls-dlobj.exp (gdb build with -O0, as usual).
When building gdb with Address Sanitizer (and still with -O0), I always run
into timeouts, though it may differ where in the test-case.
I can address this using with_timeout_factor, and the test-case finishes after
a while without timeouts:
...
real 2m30.139s
user 2m32.834s
sys 0m1.777s
...
But the preferred way to deal with this is to cut up the long operation in
smaller observable steps, each with their own timeout, so I tried out
eliminating the use of continue in the test-case, and using next instead.
In order not to spent too much time stepping through for loops like this:
...
for (i = 1; i <= 4; i++)
s0 (i, 10 + i);
...
I rewrote those to a single line.
With this new approach, I get instead:
...
real 0m5.950s
user 0m8.239s
sys 0m1.318s
...
I'm not sure why there's such a big difference in execution time, but the
functionality of the test-case hasn't changed, so I'm assuming this is related
to Address Sanitizer behavior.
Tested on x86_64-linux.
PR testsuite/33707
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33707
---
gdb/testsuite/gdb.base/tls-dlobj.c | 150 +++++++++------------------
gdb/testsuite/gdb.base/tls-dlobj.exp | 35 +++----
2 files changed, 65 insertions(+), 120 deletions(-)
diff --git a/gdb/testsuite/gdb.base/tls-dlobj.c b/gdb/testsuite/gdb.base/tls-dlobj.c
index b6dc6e45e93..e99d7a590c1 100644
--- a/gdb/testsuite/gdb.base/tls-dlobj.c
+++ b/gdb/testsuite/gdb.base/tls-dlobj.c
@@ -99,20 +99,13 @@ main (int argc, char **argv)
use_it (0); /* main-breakpoint-1 */
/* Set TLS variables in main program and all libraries. */
- for (i = 1; i <= 4; i++)
- s0 (i, 10 + i);
- for (i = 1; i <= 4; i++)
- s1 (i, 110 + i);
- for (i = 1; i <= 4; i++)
- s2 (i, 210 + i);
- for (i = 1; i <= 4; i++)
- s3 (i, 310 + i);
- for (i = 1; i <= 4; i++)
- s4 (i, 410 + i);
- for (i = 1; i <= 4; i++)
- s10 (i, 1010 + i);
- for (i = 1; i <= 4; i++)
- s11 (i, 1110 + i);
+ for (i = 1; i <= 4; i++) s0 (i, 10 + i);
+ for (i = 1; i <= 4; i++) s1 (i, 110 + i);
+ for (i = 1; i <= 4; i++) s2 (i, 210 + i);
+ for (i = 1; i <= 4; i++) s3 (i, 310 + i);
+ for (i = 1; i <= 4; i++) s4 (i, 410 + i);
+ for (i = 1; i <= 4; i++) s10 (i, 1010 + i);
+ for (i = 1; i <= 4; i++) s11 (i, 1110 + i);
use_it (0); /* main-breakpoint-2 */
@@ -124,16 +117,11 @@ main (int argc, char **argv)
/* Set TLS variables in main program and in libraries which are still
loaded. */
- for (i = 1; i <= 4; i++)
- s0 (i, 20 + i);
- for (i = 1; i <= 4; i++)
- s1 (i, 120 + i);
- for (i = 1; i <= 4; i++)
- s4 (i, 420 + i);
- for (i = 1; i <= 4; i++)
- s10 (i, 1020 + i);
- for (i = 1; i <= 4; i++)
- s11 (i, 1120 + i);
+ for (i = 1; i <= 4; i++) s0 (i, 20 + i);
+ for (i = 1; i <= 4; i++) s1 (i, 120 + i);
+ for (i = 1; i <= 4; i++) s4 (i, 420 + i);
+ for (i = 1; i <= 4; i++) s10 (i, 1020 + i);
+ for (i = 1; i <= 4; i++) s11 (i, 1120 + i);
use_it (0); /* main-breakpoint-3 */
@@ -141,18 +129,12 @@ main (int argc, char **argv)
h3 = load_dso (OBJ3, 3, &s3);
/* Set TLS vars again; currently, only lib2 is not loaded. */
- for (i = 1; i <= 4; i++)
- s0 (i, 30 + i);
- for (i = 1; i <= 4; i++)
- s1 (i, 130 + i);
- for (i = 1; i <= 4; i++)
- s3 (i, 330 + i);
- for (i = 1; i <= 4; i++)
- s4 (i, 430 + i);
- for (i = 1; i <= 4; i++)
- s10 (i, 1030 + i);
- for (i = 1; i <= 4; i++)
- s11 (i, 1130 + i);
+ for (i = 1; i <= 4; i++) s0 (i, 30 + i);
+ for (i = 1; i <= 4; i++) s1 (i, 130 + i);
+ for (i = 1; i <= 4; i++) s3 (i, 330 + i);
+ for (i = 1; i <= 4; i++) s4 (i, 430 + i);
+ for (i = 1; i <= 4; i++) s10 (i, 1030 + i);
+ for (i = 1; i <= 4; i++) s11 (i, 1130 + i);
use_it (0); /* main-breakpoint-4 */
@@ -165,16 +147,11 @@ main (int argc, char **argv)
/* Set TLS vars; currently, lib2 and lib3 are loaded,
lib1 and lib4 are not. */
- for (i = 1; i <= 4; i++)
- s0 (i, 40 + i);
- for (i = 1; i <= 4; i++)
- s2 (i, 240 + i);
- for (i = 1; i <= 4; i++)
- s3 (i, 340 + i);
- for (i = 1; i <= 4; i++)
- s10 (i, 1040 + i);
- for (i = 1; i <= 4; i++)
- s11 (i, 1140 + i);
+ for (i = 1; i <= 4; i++) s0 (i, 40 + i);
+ for (i = 1; i <= 4; i++) s2 (i, 240 + i);
+ for (i = 1; i <= 4; i++) s3 (i, 340 + i);
+ for (i = 1; i <= 4; i++) s10 (i, 1040 + i);
+ for (i = 1; i <= 4; i++) s11 (i, 1140 + i);
use_it (0); /* main-breakpoint-5 */
@@ -186,18 +163,12 @@ main (int argc, char **argv)
/* Set TLS vars; currently, lib1, lib3, and lib4 are loaded;
lib2 is not loaded. */
- for (i = 1; i <= 4; i++)
- s0 (i, 50 + i);
- for (i = 1; i <= 4; i++)
- s1 (i, 150 + i);
- for (i = 1; i <= 4; i++)
- s3 (i, 350 + i);
- for (i = 1; i <= 4; i++)
- s4 (i, 450 + i);
- for (i = 1; i <= 4; i++)
- s10 (i, 1050 + i);
- for (i = 1; i <= 4; i++)
- s11 (i, 1150 + i);
+ for (i = 1; i <= 4; i++) s0 (i, 50 + i);
+ for (i = 1; i <= 4; i++) s1 (i, 150 + i);
+ for (i = 1; i <= 4; i++) s3 (i, 350 + i);
+ for (i = 1; i <= 4; i++) s4 (i, 450 + i);
+ for (i = 1; i <= 4; i++) s10 (i, 1050 + i);
+ for (i = 1; i <= 4; i++) s11 (i, 1150 + i);
use_it (0); /* main-breakpoint-6 */
@@ -213,16 +184,11 @@ main (int argc, char **argv)
/* Set TLS vars; currently, lib2 and lib3 are loaded;
lib1 and lib4 are not loaded. */
- for (i = 1; i <= 4; i++)
- s0 (i, 60 + i);
- for (i = 1; i <= 4; i++)
- s2 (i, 260 + i);
- for (i = 1; i <= 4; i++)
- s3 (i, 360 + i);
- for (i = 1; i <= 4; i++)
- s10 (i, 1060 + i);
- for (i = 1; i <= 4; i++)
- s11 (i, 1160 + i);
+ for (i = 1; i <= 4; i++) s0 (i, 60 + i);
+ for (i = 1; i <= 4; i++) s2 (i, 260 + i);
+ for (i = 1; i <= 4; i++) s3 (i, 360 + i);
+ for (i = 1; i <= 4; i++) s10 (i, 1060 + i);
+ for (i = 1; i <= 4; i++) s11 (i, 1160 + i);
use_it (0); /* main-breakpoint-7 */
@@ -239,20 +205,13 @@ main (int argc, char **argv)
/* Set TLS vars; currently, lib1, lib2, lib3, and lib4 are all
loaded. */
- for (i = 1; i <= 4; i++)
- s0 (i, 70 + i);
- for (i = 1; i <= 4; i++)
- s1 (i, 170 + i);
- for (i = 1; i <= 4; i++)
- s2 (i, 270 + i);
- for (i = 1; i <= 4; i++)
- s3 (i, 370 + i);
- for (i = 1; i <= 4; i++)
- s4 (i, 470 + i);
- for (i = 1; i <= 4; i++)
- s10 (i, 1070 + i);
- for (i = 1; i <= 4; i++)
- s11 (i, 1170 + i);
+ for (i = 1; i <= 4; i++) s0 (i, 70 + i);
+ for (i = 1; i <= 4; i++) s1 (i, 170 + i);
+ for (i = 1; i <= 4; i++) s2 (i, 270 + i);
+ for (i = 1; i <= 4; i++) s3 (i, 370 + i);
+ for (i = 1; i <= 4; i++) s4 (i, 470 + i);
+ for (i = 1; i <= 4; i++) s10 (i, 1070 + i);
+ for (i = 1; i <= 4; i++) s11 (i, 1170 + i);
use_it (0); /* main-breakpoint-8 */
@@ -266,14 +225,10 @@ main (int argc, char **argv)
/* Set TLS vars; currently, lib2 is loaded; lib1, lib3, and lib4 are
not. */
- for (i = 1; i <= 4; i++)
- s0 (i, 80 + i);
- for (i = 1; i <= 4; i++)
- s2 (i, 280 + i);
- for (i = 1; i <= 4; i++)
- s10 (i, 1080 + i);
- for (i = 1; i <= 4; i++)
- s11 (i, 1180 + i);
+ for (i = 1; i <= 4; i++) s0 (i, 80 + i);
+ for (i = 1; i <= 4; i++) s2 (i, 280 + i);
+ for (i = 1; i <= 4; i++) s10 (i, 1080 + i);
+ for (i = 1; i <= 4; i++) s11 (i, 1180 + i);
use_it (0); /* main-breakpoint-9 */
@@ -285,16 +240,11 @@ main (int argc, char **argv)
/* Set TLS vars; currently, lib3 and lib4 are loaded; lib1 and lib2
are not. */
- for (i = 1; i <= 4; i++)
- s0 (i, 90 + i);
- for (i = 1; i <= 4; i++)
- s3 (i, 390 + i);
- for (i = 1; i <= 4; i++)
- s4 (i, 490 + i);
- for (i = 1; i <= 4; i++)
- s10 (i, 1090 + i);
- for (i = 1; i <= 4; i++)
- s11 (i, 1190 + i);
+ for (i = 1; i <= 4; i++) s0 (i, 90 + i);
+ for (i = 1; i <= 4; i++) s3 (i, 390 + i);
+ for (i = 1; i <= 4; i++) s4 (i, 490 + i);
+ for (i = 1; i <= 4; i++) s10 (i, 1090 + i);
+ for (i = 1; i <= 4; i++) s11 (i, 1190 + i);
use_it (0); /* main-breakpoint-10 */
diff --git a/gdb/testsuite/gdb.base/tls-dlobj.exp b/gdb/testsuite/gdb.base/tls-dlobj.exp
index 68c8b781473..0b8cb35aa7d 100644
--- a/gdb/testsuite/gdb.base/tls-dlobj.exp
+++ b/gdb/testsuite/gdb.base/tls-dlobj.exp
@@ -55,6 +55,11 @@ proc gdb_test_with_xfail { cmd re cond} {
}
}
+proc next_to_main_breakpoint { n } {
+ repeat_cmd_until next "" main-breakpoint-$n \
+ "step to breakpoint: main-breakpoint-$n" 20
+}
+
proc do_tests {force_internal_tls} {
clean_restart $::testfile
if {![runto_main]} {
@@ -65,8 +70,7 @@ proc do_tests {force_internal_tls} {
gdb_test_no_output "maint set force-internal-tls-address-lookup on"
}
- gdb_breakpoint [gdb_get_line_number "main-breakpoint-1"]
- gdb_continue_to_breakpoint "main-breakpoint-1"
+ next_to_main_breakpoint 1
with_test_prefix "before assignments" {
gdb_test "print tls_main_tbss_1" ".* = 0"
@@ -100,8 +104,7 @@ proc do_tests {force_internal_tls} {
}
}
- gdb_breakpoint [gdb_get_line_number "main-breakpoint-2"]
- gdb_continue_to_breakpoint "main-breakpoint-2"
+ next_to_main_breakpoint 2
with_test_prefix "at main-breakpoint-2" {
gdb_test "print tls_main_tbss_1" ".* = 11"
@@ -117,8 +120,7 @@ proc do_tests {force_internal_tls} {
}
}
- gdb_breakpoint [gdb_get_line_number "main-breakpoint-3"]
- gdb_continue_to_breakpoint "main-breakpoint-3"
+ next_to_main_breakpoint 3
# At this point lib2 and lib3 have been unloaded. Also, TLS vars
# in remaining libraries have been changed.
@@ -137,8 +139,7 @@ proc do_tests {force_internal_tls} {
}
}
- gdb_breakpoint [gdb_get_line_number "main-breakpoint-4"]
- gdb_continue_to_breakpoint "main-breakpoint-4"
+ next_to_main_breakpoint 4
# lib3 has been loaded again; lib2 is the only one not loaded.
@@ -157,8 +158,7 @@ proc do_tests {force_internal_tls} {
}
}
- gdb_breakpoint [gdb_get_line_number "main-breakpoint-5"]
- gdb_continue_to_breakpoint "main-breakpoint-5"
+ next_to_main_breakpoint 5
# lib2 and lib3 are loaded; lib1 and lib4 are not.
@@ -177,8 +177,7 @@ proc do_tests {force_internal_tls} {
}
}
- gdb_breakpoint [gdb_get_line_number "main-breakpoint-6"]
- gdb_continue_to_breakpoint "main-breakpoint-6"
+ next_to_main_breakpoint 6
# lib1, lib3 and lib4 are loaded; lib2 is not loaded.
@@ -197,8 +196,7 @@ proc do_tests {force_internal_tls} {
}
}
- gdb_breakpoint [gdb_get_line_number "main-breakpoint-7"]
- gdb_continue_to_breakpoint "main-breakpoint-7"
+ next_to_main_breakpoint 7
# lib2 and lib3 are loaded; lib1 and lib4 are not.
@@ -217,8 +215,7 @@ proc do_tests {force_internal_tls} {
}
}
- gdb_breakpoint [gdb_get_line_number "main-breakpoint-8"]
- gdb_continue_to_breakpoint "main-breakpoint-8"
+ next_to_main_breakpoint 8
# lib1, lib2, lib3, and lib4 are all loaded.
@@ -236,8 +233,7 @@ proc do_tests {force_internal_tls} {
}
}
- gdb_breakpoint [gdb_get_line_number "main-breakpoint-9"]
- gdb_continue_to_breakpoint "main-breakpoint-9"
+ next_to_main_breakpoint 9
# lib2 is loaded; lib1, lib3, and lib4 are not.
@@ -255,8 +251,7 @@ proc do_tests {force_internal_tls} {
}
}
- gdb_breakpoint [gdb_get_line_number "main-breakpoint-10"]
- gdb_continue_to_breakpoint "main-breakpoint-10"
+ next_to_main_breakpoint 10
# lib3 and lib4 are loaded; lib1 and lib2 are not.
base-commit: fc9bd3b1baffa2af37d494751012d25618fdede5
--
2.51.0
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] [gdb/testsuite] Fix timeouts in gdb.base/tls-dlobj.exp
2026-01-07 9:19 [PATCH] [gdb/testsuite] Fix timeouts in gdb.base/tls-dlobj.exp Tom de Vries
@ 2026-01-09 4:00 ` Kevin Buettner
2026-01-09 12:40 ` Tom de Vries
0 siblings, 1 reply; 5+ messages in thread
From: Kevin Buettner @ 2026-01-09 4:00 UTC (permalink / raw)
To: Tom de Vries; +Cc: gdb-patches
Hi Tom,
I'll state at the outset that I don't have any firm objections to the
things you've done, but there are some things I'd like to understand
better first.
On Wed, 7 Jan 2026 10:19:42 +0100
Tom de Vries <tdevries@suse.de> wrote:
> When running the testsuite on a busy system, occasionally I run into
> timeouts in test-case gdb.base/tls-dlobj.exp (gdb build with -O0, as
> usual).
>
> When building gdb with Address Sanitizer (and still with -O0), I always
> run into timeouts, though it may differ where in the test-case.
>
> I can address this using with_timeout_factor, and the test-case finishes
> after a while without timeouts:
> ...
> real 2m30.139s
> user 2m32.834s
> sys 0m1.777s
> ...
>
> But the preferred way to deal with this is to cut up the long operation in
> smaller observable steps, each with their own timeout, so I tried out
> eliminating the use of continue in the test-case, and using next instead.
This is the key thing that I don't understand. Why should using 'next'
be faster than continuing to a breakpoint?
> In order not to spent too much time stepping through for loops like this:
> ...
> for (i = 1; i <= 4; i++)
> s0 (i, 10 + i);
> ...
> I rewrote those to a single line.
If using 'next' is truly better, then I'm fine with that change.
> With this new approach, I get instead:
> ...
> real 0m5.950s
> user 0m8.239s
> sys 0m1.318s
Wow - that's a truly astounding difference.
Kevin
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] [gdb/testsuite] Fix timeouts in gdb.base/tls-dlobj.exp
2026-01-09 4:00 ` Kevin Buettner
@ 2026-01-09 12:40 ` Tom de Vries
2026-01-09 13:02 ` Tom de Vries
2026-01-10 9:56 ` Tom de Vries
0 siblings, 2 replies; 5+ messages in thread
From: Tom de Vries @ 2026-01-09 12:40 UTC (permalink / raw)
To: Kevin Buettner; +Cc: gdb-patches
On 1/9/26 5:00 AM, Kevin Buettner wrote:
> Hi Tom,
>
> I'll state at the outset that I don't have any firm objections to the
> things you've done, but there are some things I'd like to understand
> better first.
>
Hi Kevin,
thanks for the review.
> On Wed, 7 Jan 2026 10:19:42 +0100
> Tom de Vries <tdevries@suse.de> wrote:
>
>> When running the testsuite on a busy system, occasionally I run into
>> timeouts in test-case gdb.base/tls-dlobj.exp (gdb build with -O0, as
>> usual).
>>
>> When building gdb with Address Sanitizer (and still with -O0), I always
>> run into timeouts, though it may differ where in the test-case.
>>
>> I can address this using with_timeout_factor, and the test-case finishes
>> after a while without timeouts:
>> ...
>> real 2m30.139s
>> user 2m32.834s
>> sys 0m1.777s
>> ...
>>
>> But the preferred way to deal with this is to cut up the long operation in
>> smaller observable steps, each with their own timeout, so I tried out
>> eliminating the use of continue in the test-case, and using next instead.
>
> This is the key thing that I don't understand. Why should using 'next'
> be faster than continuing to a breakpoint?
If you're asking about my intention, I didn't use next expecting it to
be faster, it just happened to be so.
But as you point out, it's good to understand why, so I dug a little deeper.
I attached at the point that gdb is not making progress, and did a
backtrace:
...
(gdb) bt
#0 0x00007f094611fe94 in __asan::QuickCheckForUnpoisonedRegion
(beg=135279688646848, size=16)
at ../../../../libsanitizer/asan/asan_interceptors_memintrinsics.h:33
#1 ___interceptor_memcpy (dst=0x7d194efaf420, src=0x7b0941c980c0, size=16)
at
../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors_memintrinsics.inc:115
#2 0x0000000001377273 in abbrev_table::read (section=0x7ca9431186f8,
sect_off=34549)
at /data/vries/gdb/src/gdb/dwarf2/abbrev.c:225
#3 0x000000000153daad in cutu_reader::cutu_reader (this=0x7b0941dd5d30,
this_cu=...,
per_objfile=..., abbrev_table=0x0, existing_cu=0x0, skip_partial=true,
pretend_language=language_minimal, abbrev_cache=0x0) at
/data/vries/gdb/src/gdb/dwarf2/read.c:3138
#4 0x000000000153498c in dw2_get_file_names (this_cu=0x7b8943068aa0,
per_objfile=0x7c4943004240)
at /data/vries/gdb/src/gdb/dwarf2/read.c:1902
#5 0x00000000015360cf in dw_search_file_matcher
(per_objfile=0x7c4943004240, cus_to_skip=...,
file_matcher=...) at /data/vries/gdb/src/gdb/dwarf2/read.c:2100
#6 0x000000000158acb5 in cooked_index_functions::search
(this=0x7b294305bf30,
objfile=0x7c4943004040, file_matcher=..., lookup_name=0x0,
symbol_matcher=..., listener=...,
search_flags=..., domain=..., lang_matcher=...) at
/data/vries/gdb/src/gdb/dwarf2/read.c:14683
#7 0x000000000222560a in objfile::map_symtabs_matching_filename
(this=0x7c4943004040,
name=0x7b6942fec8c0
"/data/vries/gdb/src/gdb/testsuite/gdb.base/tls-dlobj.c",
real_path=0x7b7943034560
"/data/vries/gdb/binutils-gdb.git/gdb/testsuite/gdb.base/tls-dlobj.c",
callback=...) at /data/vries/gdb/src/gdb/symfile-debug.c:268
#8 0x00000000022761e7 in iterate_over_symtabs (pspace=0x7c1942ff88c0,
name=0x7b6942fec8c0
"/data/vries/gdb/src/gdb/testsuite/gdb.base/tls-dlobj.c", callback=...)
at /data/vries/gdb/src/gdb/symtab.c:649
#9 0x00000000019b731b in collect_symtabs_from_filename (
file=0x7b6942fec8c0
"/data/vries/gdb/src/gdb/testsuite/gdb.base/tls-dlobj.c",
search_pspace=0x7c1942ff88c0) at
/data/vries/gdb/src/gdb/linespec.c:3633
#10 0x00000000019b74b9 in symtabs_from_filename (
filename=0x7b6942fec8c0
"/data/vries/gdb/src/gdb/testsuite/gdb.base/tls-dlobj.c",
search_pspace=0x7c1942ff88c0) at
/data/vries/gdb/src/gdb/linespec.c:3649
#11 0x00000000019ae28f in convert_explicit_location_spec_to_linespec
(self=0x7b0941f54510,
result=0x7b0941f545a0,
source_filename=0x7b6942fec8c0
"/data/vries/gdb/src/gdb/testsuite/gdb.base/tls-dlobj.c",
function_name=0x0, fname_match_type=symbol_name_match_type::WILD,
label_name=0x0, line_offset=...)
at /data/vries/gdb/src/gdb/linespec.c:2342
#12 0x00000000019aeaf7 in convert_explicit_location_spec_to_sals
(self=0x7b0941f54510,
result=0x7b0941f545a0, explicit_spec=0x7b8943010aa0) at
/data/vries/gdb/src/gdb/linespec.c:2403
#13 0x00000000019b2cce in location_spec_to_sals (parser=0x7b0941f544e0,
locspec=0x7b8943010aa0)
at /data/vries/gdb/src/gdb/linespec.c:3078
#14 0x00000000019b321d in decode_line_full (locspec=0x7b8943010aa0,
flags=1,
search_pspace=0x7c1942ff88c0, default_symtab=0x0, default_line=0,
canonical=0x7b0941c04f30,
select_mode=0x4123460 <multiple_symbols_all> "all", filter=0x0)
at /data/vries/gdb/src/gdb/linespec.c:3124
#15 0x000000000100384f in code_breakpoint::decode_location_spec
(this=0x7c194338e840,
locspec=0x7b8943010aa0, search_pspace=0x7c1942ff88c0)
at /data/vries/gdb/src/gdb/breakpoint.c:12205
#16 0x000000000100a261 in code_breakpoint::location_spec_to_sals
(this=0x7c194338e840,
locspec=0x7b8943010aa0, search_pspace=0x7c1942ff88c0,
found=0x7b0941e81a30)
at /data/vries/gdb/src/gdb/breakpoint.c:13138
#17 0x000000000100aead in code_breakpoint::re_set_default
(this=0x7c194338e840,
filter_pspace=0x7c1942ff88c0) at
/data/vries/gdb/src/gdb/breakpoint.c:13220
#18 0x000000000100221a in code_breakpoint::re_set (this=0x7c194338e840,
pspace=0x7c1942ff88c0)
at /data/vries/gdb/src/gdb/breakpoint.c:12017
#19 0x000000000100b647 in breakpoint_re_set () at
/data/vries/gdb/src/gdb/breakpoint.c:13275
#20 0x0000000002199911 in solib_add (pattern=0x0, from_tty=0, readsyms=1)
--Type <RET> for more, q to quit, c to continue without paging--
at /data/vries/gdb/src/gdb/solib.c:999
#21 0x000000000219d534 in handle_solib_event () at
/data/vries/gdb/src/gdb/solib.c:1399
#22 0x0000000000fd26ce in bpstat_stop_status (aspace=0x7b4942fe6f90,
bp_addr=140737353957264,
thread=0x7c794307f800, ws=..., stop_chain=0x0) at
/data/vries/gdb/src/gdb/breakpoint.c:5962
#23 0x000000000192d293 in handle_signal_stop (ecs=0x7b0941f33ef0)
at /data/vries/gdb/src/gdb/infrun.c:7131
#24 0x0000000001929d8d in handle_inferior_event (ecs=0x7b0941f33ef0)
at /data/vries/gdb/src/gdb/infrun.c:6575
#25 0x000000000191e6b8 in fetch_inferior_event () at
/data/vries/gdb/src/gdb/infrun.c:4714
#26 0x00000000018b9eb0 in inferior_event_handler (event_type=INF_REG_EVENT)
at /data/vries/gdb/src/gdb/inf-loop.c:42
#27 0x0000000001a1b4bf in handle_target_event (error=0, client_data=0x0)
at /data/vries/gdb/src/gdb/linux-nat.c:4449
#28 0x0000000003b07ec2 in handle_file_event (file_ptr=0x7b7943012a60,
ready_mask=1)
at /data/vries/gdb/src/gdbsupport/event-loop.cc:551
#29 0x0000000003b08cb4 in gdb_wait_for_event (block=0)
at /data/vries/gdb/src/gdbsupport/event-loop.cc:672
#30 0x0000000003b05e37 in gdb_do_one_event (mstimeout=-1)
at /data/vries/gdb/src/gdbsupport/event-loop.cc:216
#31 0x0000000001197fe4 in interp::do_one_event (this=0x7b4942fee550,
mstimeout=-1)
at /data/vries/gdb/src/gdb/interps.h:93
#32 0x00000000023a833c in wait_sync_command_done () at
/data/vries/gdb/src/gdb/top.c:418
#33 0x00000000023a84e4 in maybe_wait_sync_command_done (was_sync=0)
at /data/vries/gdb/src/gdb/top.c:435
#34 0x00000000023a927d in execute_command (p=0x7b0941c0e458 "", from_tty=0)
at /data/vries/gdb/src/gdb/top.c:565
#35 0x00000000016893b9 in command_handler (command=0x7b0941c0e450
"continue")
at /data/vries/gdb/src/gdb/event-top.c:611
#36 0x00000000023a7b0c in read_command_file (stream=0x7c5943011900)
at /data/vries/gdb/src/gdb/top.c:333
#37 0x00000000011b0659 in script_from_file (stream=0x7c5943011900,
file=0x7ffc256f7d6b "outputs/gdb.base/tls-dlobj/gdb.in.1")
at /data/vries/gdb/src/gdb/cli/cli-script.c:1703
#38 0x000000000115579b in source_script_from_stream (stream=0x7c5943011900,
file=0x7ffc256f7d6b "outputs/gdb.base/tls-dlobj/gdb.in.1",
file_to_open=0x7b4942fee7d0 "outputs/gdb.base/tls-dlobj/gdb.in.1")
at /data/vries/gdb/src/gdb/cli/cli-cmds.c:706
#39 0x0000000001155a4d in source_script_with_search (
file=0x7ffc256f7d6b "outputs/gdb.base/tls-dlobj/gdb.in.1",
from_tty=0, search_path=0)
at /data/vries/gdb/src/gdb/cli/cli-cmds.c:751
#40 0x0000000001155ba5 in source_script (file=0x7ffc256f7d6b
"outputs/gdb.base/tls-dlobj/gdb.in.1",
from_tty=0) at /data/vries/gdb/src/gdb/cli/cli-cmds.c:760
#41 0x0000000001b03bf1 in catch_command_errors (command=0x1155b71
<source_script(char const*, int)>,
arg=0x7ffc256f7d6b "outputs/gdb.base/tls-dlobj/gdb.in.1",
from_tty=0, do_bp_actions=false)
at /data/vries/gdb/src/gdb/main.c:510
#42 0x0000000001b041ea in execute_cmdargs (cmdarg_vec=0x7b0942003a50,
file_type=CMDARG_FILE,
cmd_type=CMDARG_COMMAND, ret=0x7b0942003830) at
/data/vries/gdb/src/gdb/main.c:606
#43 0x0000000001b07864 in captured_main_1 (context=0x7b0941c97da0)
at /data/vries/gdb/src/gdb/main.c:1348
#44 0x0000000001b07fa3 in captured_main (context=0x7b0941c97da0)
at /data/vries/gdb/src/gdb/main.c:1371
#45 0x0000000001b080d5 in gdb_main (args=0x7b0941c97da0) at
/data/vries/gdb/src/gdb/main.c:1400
#46 0x0000000000c3ab13 in main (argc=13, argv=0x7ffc256f6158) at
/data/vries/gdb/src/gdb/gdb.c:38
...
I issued finish until I found that finishing took noticeable time, which
was the case for breakpoint_re_set.
I then tried the following experiment: I made all main breakpoints in
the test-case temporary, which brought total time down from ~2m30s to ~30s.
I then noticed that the debuginfo being read is for glibc, so I did
"sudo zypper remove glibc-debuginfo" and tried again, which brought
total time down from ~2m30s to ~3s.
So I guess the answer is that re-inserting breakpoints in presence of
glibc debug info is slow, and that having less breakpoints to re-insert
(by making them temporary, or by using next) speeds up the test-case.
So, why is this so slow?
After debugging, I came up with the following patch:
...
$ git diff
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 2e222766579..1e652b8e70e 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -1900,7 +1900,9 @@ dw2_get_file_names (dwarf2_per_cu *this_cu,
dwarf2_per_objfile *per_objfi
le)
cutu_reader reader (*this_cu, *per_objfile, nullptr,
per_objfile->get_cu (this_cu), true, language_minimal,
nullptr);
- if (!reader.is_dummy ())
+ if (reader.is_dummy ())
+ this_cu->files_read = true;
+ else
dw2_get_file_names_reader (reader.cu (), reader.top_level_die ());
return this_cu->file_names;
...
which makes sure we don't try to read dummy CUs over and over again.
Using this patch, I get to ~15s, and then making the breakpoints
temporary I get to ~7s.
So I will resubmit a v2 patch that uses the temporary breakpoint approach.
But I will also file a PR for the dw2_get_file_names issue.
Thanks again for asking that question :)
- Tom
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-01-10 9:56 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-01-07 9:19 [PATCH] [gdb/testsuite] Fix timeouts in gdb.base/tls-dlobj.exp Tom de Vries
2026-01-09 4:00 ` Kevin Buettner
2026-01-09 12:40 ` Tom de Vries
2026-01-09 13:02 ` Tom de Vries
2026-01-10 9:56 ` Tom de Vries
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox