[PATCH 1/2] [gdb/testsuite] Fix timeout in do_self_tests

[PATCH 1/2] [gdb/testsuite] Fix timeout in do_self_tests

[Tom de Vries]

I noticed a patch reporting a timeout in the selftests on slow systems [1].

I tried to see if I could trigger some timeouts.

With the following setup:
- gdb build with -O0
- running gdb.gdb/*.exp
- aarch64-linux platform
- all cpu threads set to the lowest value: 600 Mhz
- taskset -c 0
I managed to trigger timeouts in the form of warnings:
...
(gdb) set height 0
WARNING: Couldn't set the height to 0
set width 0
WARNING: Couldn't set the width to 0.
break main
(gdb) set width 0
(gdb) break main
Breakpoint 1 at 0x41767c: file gdb.c, line 30.
(gdb)
...
in both gdb.gdb/selftest.exp and gdb.gdb/python-helper.exp.

Note that this is extra slow because the default worker-threads is set using
std::thread::hardware_concurrency, which is 8 even though we use taskset -c 0:
...
$ taskset -c 0 gdb -q -batch -ex "maint show worker-thread"
The number of worker threads GDB can use is the default (currently 8).
...
making 8 worker threads compete for 1 cpu thread.

The timeouts are triggered in do_self_tests by gdb loading the symbols in the
background, making the effort to do so overlap with subsequent commands.

Fix this using "maintenance set dwarf synchronous on".

[1] https://sourceware.org/pipermail/gdb-patches/2026-September/230133.html
---
 gdb/testsuite/lib/selftest-support.exp | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/lib/selftest-support.exp b/gdb/testsuite/lib/selftest-support.exp
index bcfa99e8f34..cc9ad0b4127 100644
--- a/gdb/testsuite/lib/selftest-support.exp
+++ b/gdb/testsuite/lib/selftest-support.exp
@@ -246,7 +246,18 @@ proc do_self_tests {body} {
 	    set ::GDB "libtool --mode=execute $::GDB"
 	}
 
-	set ::GDBFLAGS "$::GDBFLAGS $file"
+	# By default, dwarf synchronous is off, so the effort to load $file
+	# may be spread over subsequent commands and cause timeouts on slow
+	# systems.  Use "maintenance set dwarf synchronous on", to make sure
+	# $file is completely loaded during gdb_start.
+	# Proc gdb_start has a timeout of 600 for spawning gdb, which seems
+	# sufficient to handle both spawning gdb and loading $file.
+	# Using gdb_load would permit a timeout of 120s just for loading
+	# $file, but we're not using that because we want libtool to
+	# update $file.
+	append ::GDBFLAGS \
+	    " " -iex " " {"maintenance set dwarf synchronous on"} \
+	    " " $file
 	gdb_start
     }
 

base-commit: 668300e5c9e1e8baa55d9402cdd4dff5e81601d2
-- 
2.51.0

[PATCH 2/2] [gdb] Exclude unavailable hardware threads in default worker-threads

[Tom de Vries]

The default worker-threads is set to the number of hardware threads:
...
$ gdb -q -batch -ex "maint show worker-thread"
The number of worker threads GDB can use is the default (currently 8).
...
but does not take into account how many of those are actually available.

If we reduce the amount of available threads to 1, we get the same answer:
...
$ taskset -c 0 gdb -q -batch -ex "maint show worker-thread"
The number of worker threads GDB can use is the default (currently 8).
...

Fix this on linux using sched_getaffinity:
...
$ taskset -c 0 gdb -q -batch -ex "maint show worker-thread"
The number of worker threads GDB can use is the default (currently 1).
$ gdb -q -batch -ex "maint show worker-thread"
The number of worker threads GDB can use is the default (currently 8).
...
---
 gdb/maint.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/gdb/maint.c b/gdb/maint.c
index 1daa6ce1d2e..fbddfe15591 100644
--- a/gdb/maint.c
+++ b/gdb/maint.c
@@ -47,6 +47,10 @@
 #include "cli/cli-style.h"
 #include "cli/cli-cmds.h"
 
+#ifdef __linux__
+#include <sched.h>
+#endif
+
 static void maintenance_do_deprecate (const char *, int);
 
 #ifndef _WIN32
@@ -882,6 +886,20 @@ update_thread_pool_size ()
 	 systems.  */
       const int max_thread_count = 8;
       n_threads = std::min (hardware_threads, max_thread_count);
+
+      if (n_threads > 1)
+	{
+	  /* Exclude unavailable hardware threads (for instance made
+	     unavailable using taskset).  */
+#ifdef __linux__
+	  cpu_set_t cpus;
+	  int res = sched_getaffinity (getpid (), sizeof (cpu_set_t), &cpus);
+	  if (res == 0)
+	    n_threads = std::min (n_threads, CPU_COUNT (&cpus));
+#else
+	  /* Todo: handle other platforms.  */
+#endif
+	}
     }
 
   gdb::thread_pool::g_thread_pool->set_thread_count (n_threads);
-- 
2.51.0

Re: [PATCH 2/2] [gdb] Exclude unavailable hardware threads in default worker-threads

[Thiago Jung Bauermann]

Tom de Vries <tdevries@suse.de> writes:

> The default worker-threads is set to the number of hardware threads:
> ...
> $ gdb -q -batch -ex "maint show worker-thread"
> The number of worker threads GDB can use is the default (currently 8).
> ...
> but does not take into account how many of those are actually available.
>
> If we reduce the amount of available threads to 1, we get the same answer:
> ...
> $ taskset -c 0 gdb -q -batch -ex "maint show worker-thread"
> The number of worker threads GDB can use is the default (currently 8).
> ...
>
> Fix this on linux using sched_getaffinity:
> ...
> $ taskset -c 0 gdb -q -batch -ex "maint show worker-thread"
> The number of worker threads GDB can use is the default (currently 1).
> $ gdb -q -batch -ex "maint show worker-thread"
> The number of worker threads GDB can use is the default (currently 8).
> ...
> ---
>  gdb/maint.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)

This is a nice improvement. At least some good came out of my red
herring. Thanks!

One comment, but:

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

> diff --git a/gdb/maint.c b/gdb/maint.c
> index 1daa6ce1d2e..fbddfe15591 100644
> --- a/gdb/maint.c
> +++ b/gdb/maint.c
> @@ -47,6 +47,10 @@
>  #include "cli/cli-style.h"
>  #include "cli/cli-cmds.h"
>  
> +#ifdef __linux__
> +#include <sched.h>

The sched_getaffinity(2) man page mentions that one should define
_GNU_SOURCE before including <sched.h>

> +#endif
> +
>  static void maintenance_do_deprecate (const char *, int);
>  
>  #ifndef _WIN32
> @@ -882,6 +886,20 @@ update_thread_pool_size ()
>  	 systems.  */
>        const int max_thread_count = 8;
>        n_threads = std::min (hardware_threads, max_thread_count);
> +
> +      if (n_threads > 1)
> +	{
> +	  /* Exclude unavailable hardware threads (for instance made
> +	     unavailable using taskset).  */
> +#ifdef __linux__
> +	  cpu_set_t cpus;
> +	  int res = sched_getaffinity (getpid (), sizeof (cpu_set_t), &cpus);
> +	  if (res == 0)
> +	    n_threads = std::min (n_threads, CPU_COUNT (&cpus));
> +#else
> +	  /* Todo: handle other platforms.  */
> +#endif
> +	}
>      }
>  
>    gdb::thread_pool::g_thread_pool->set_thread_count (n_threads);

-- 
Thiago
(he/him)

Re: [PATCH 2/2] [gdb] Exclude unavailable hardware threads in default worker-threads

[Tom de Vries]

On 9/7/26 6:44 AM, Thiago Jung Bauermann wrote:
> The sched_getaffinity(2) man page mentions that one should define
> _GNU_SOURCE before including <sched.h>

Hi Thiago,

thanks for the review.

Correct, but we seem to be setting this using configure.

Still, I should probably test for it in the ifdef around the use of 
sched_getaffinity.

Thanks,
- Tom

Re: [PATCH 2/2] [gdb] Exclude unavailable hardware threads in default worker-threads

[Tom de Vries]

On 9/7/26 6:44 AM, Thiago Jung Bauermann wrote:
> his is a nice improvement. At least some good came out of my red
> herring. Thanks!
> 
> One comment, but:
> 
> Reviewed-by: Thiago Jung Bauermann<thiago.bauermann@linaro.org>

I'm hoping to find time to get this working as well for (some 
compatibility setups for) Windows before committing.

I used to have a freebsd setup on my laptop, but a fedora update has 
rendered it unbootable, so I'll skip that for now.

Thanks,
- Tom

Re: [PATCH 2/2] [gdb] Exclude unavailable hardware threads in default worker-threads

[Tom de Vries]

On 9/9/26 2:02 PM, Tom de Vries wrote:
> On 9/7/26 6:44 AM, Thiago Jung Bauermann wrote:
>> his is a nice improvement. At least some good came out of my red
>> herring. Thanks!
>>
>> One comment, but:
>>
>> Reviewed-by: Thiago Jung Bauermann<thiago.bauermann@linaro.org>
> 
> I'm hoping to find time to get this working as well for (some 
> compatibility setups for) Windows before committing.
> 

I tried out msys2, and the problem didn't reproduce there when using 
taskset.  There's a windows native tool called start that I tried as 
well, but I didn't get it to work.

The problem did reproduce with cygwin, and the solution was to just use 
the same fix for __CYGWIN__ as for __linux___, so I've committed that.

Thanks,
- Tom

> I used to have a freebsd setup on my laptop, but a fedora update has 
> rendered it unbootable, so I'll skip that for now.
> 
> Thanks,
> - Tom

Re: [PATCH 1/2] [gdb/testsuite] Fix timeout in do_self_tests

[Thiago Jung Bauermann]

Tom de Vries <tdevries@suse.de> writes:

> I noticed a patch reporting a timeout in the selftests on slow systems [1].
>
> I tried to see if I could trigger some timeouts.
>
> With the following setup:
> - gdb build with -O0
> - running gdb.gdb/*.exp
> - aarch64-linux platform
> - all cpu threads set to the lowest value: 600 Mhz
> - taskset -c 0
> I managed to trigger timeouts in the form of warnings:
> ...
> (gdb) set height 0
> WARNING: Couldn't set the height to 0
> set width 0
> WARNING: Couldn't set the width to 0.
> break main
> (gdb) set width 0
> (gdb) break main
> Breakpoint 1 at 0x41767c: file gdb.c, line 30.
> (gdb)
> ...
> in both gdb.gdb/selftest.exp and gdb.gdb/python-helper.exp.
>
> Note that this is extra slow because the default worker-threads is set using
> std::thread::hardware_concurrency, which is 8 even though we use taskset -c 0:
> ...
> $ taskset -c 0 gdb -q -batch -ex "maint show worker-thread"
> The number of worker threads GDB can use is the default (currently 8).
> ...
> making 8 worker threads compete for 1 cpu thread.
>
> The timeouts are triggered in do_self_tests by gdb loading the symbols in the
> background, making the effort to do so overlap with subsequent commands.
>
> Fix this using "maintenance set dwarf synchronous on".
>
> [1] https://sourceware.org/pipermail/gdb-patches/2026-September/230133.html
> ---
>  gdb/testsuite/lib/selftest-support.exp | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)

I also see the timeouts above in gdb.gdb/python-helper.exp with an
especially slow setup that I use sometimes: running the GDB testsuite in
a QEMU TCG aarch64 VM on an old x86_64 server. And this patch solves
them.

This is with GDB built with -O0, but as I mentioned in an email to Simon
perhaps I should switch to -Og. I still have to check how much of a
difference it makes.

I don't see the timeouts on a QEMU TCG aarch64 VM running on my faster
x86_64 laptop, though.

Also, when I run the testsuite on the slow setup I normally generously
increate gdb_test_timeout.

All this to say that I see value in this patch, but it's somewhat niche.

If you do decide to apply it:

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

-- 
Thiago
(he/him)

Re: [PATCH 1/2] [gdb/testsuite] Fix timeout in do_self_tests

[Tom de Vries]

On 9/7/26 6:36 AM, Thiago Jung Bauermann wrote:
> All this to say that I see value in this patch, but it's somewhat niche.
> 
> If you do decide to apply it:
> 
> Reviewed-by: Thiago Jung Bauermann<thiago.bauermann@linaro.org>
> Tested-by: Thiago Jung Bauermann<thiago.bauermann@linaro.org>
> 

Hi Thiago,

thank you for the review.

I've pushed this, but unfortunately forgotten to add your tags.  My 
apologies.

Thanks,
- Tom

Re: [PATCH 1/2] [gdb/testsuite] Fix timeout in do_self_tests

[Thiago Jung Bauermann]

Tom de Vries <tdevries@suse.de> writes:

> On 9/7/26 6:36 AM, Thiago Jung Bauermann wrote:
>> All this to say that I see value in this patch, but it's somewhat niche.
>> If you do decide to apply it:
>> Reviewed-by: Thiago Jung Bauermann<thiago.bauermann@linaro.org>
>> Tested-by: Thiago Jung Bauermann<thiago.bauermann@linaro.org>
>> 
>
> Hi Thiago,
>
> thank you for the review.
>
> I've pushed this, but unfortunately forgotten to add your tags.  My apologies.

No problem at all. Thank you for the patches.

-- 
Thiago
(he/him)