Hmm, interesting, the first timeout went away again.

I suppose the timeouts are related to some mechanism that prevents frequency scaling while charging and/or on low battery. [ Normally I don't run into this because the laptop is sitting on a desk at home with charger plugged in and battery charged 100%, but I'm currently traveling. ]

Consequently, I get the baseline 400Mhz instead of the boost frequency.

I found a way to reproduce this.

Pick a single cpu (say 7, an efficiency core), divide the boost frequency (3500Mhz) [1] by the base frequency (400Mhz): 8.75.  Round to 9.  Substract one and do:
...
$ taskset -c 7 stress -c 8
...
and run the test-case also using taskset -c 7.  That should cap the test-case to roughly the base frequency.

Using this approach, I can reproduce the timeout again.

[1] https://www.intel.com/content/www/us/en/products/sku/226454/intel-core-i71250u-processor-12m-cache-up-to-4-70-ghz/specifications.html

> FAIL: gdb.ada/info_exc.exp: info exceptions (timeout)
> FAIL: gdb.ada/mi_exc_info.exp: -info-ada-exceptions (timeout)

Filed PR32182 for these.

For call_pn.exp, maybe passing an argument to
"maint expand-symtabs" would work.

... like

diff --git a/gdb/testsuite/gdb.ada/call_pn.exp b/gdb/testsuite/gdb.ada/call_pn.exp
index 5d7e828b584..ec0561dced9 100644
--- a/gdb/testsuite/gdb.ada/call_pn.exp
+++ b/gdb/testsuite/gdb.ada/call_pn.exp
@@ -35,7 +35,7 @@ if {![runto "foo.adb:$bp_location"]} {
 # related to PR25764 - "LOC_UNRESOLVED symbol missing from partial symtab".
 # Stabilize test results by ensuring that the xfail triggers for the "before"
 # print.
-gdb_test_no_output "maint expand-symtabs"
+gdb_test_no_output "maint expand-symtabs \\(pck\\|foo\\)\\.adb"
 
 # The xfail is for PR gcc/94469, which occurs with target board
 # unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects and gcc-8 and later.

(In reply to Tom Tromey from comment #4)
> ... like
> 
> diff --git a/gdb/testsuite/gdb.ada/call_pn.exp
> b/gdb/testsuite/gdb.ada/call_pn.exp
> index 5d7e828b584..ec0561dced9 100644
> --- a/gdb/testsuite/gdb.ada/call_pn.exp
> +++ b/gdb/testsuite/gdb.ada/call_pn.exp
> @@ -35,7 +35,7 @@ if {![runto "foo.adb:$bp_location"]} {
>  # related to PR25764 - "LOC_UNRESOLVED symbol missing from partial symtab".
>  # Stabilize test results by ensuring that the xfail triggers for the
> "before"
>  # print.
> -gdb_test_no_output "maint expand-symtabs"
> +gdb_test_no_output "maint expand-symtabs \\(pck\\|foo\\)\\.adb"
>  
>  # The xfail is for PR gcc/94469, which occurs with target board
>  # unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects and gcc-8 and later.

I have a patch for this in a patch series that I'm finalizing, I used "maint expand-symtabs $src" though.  I'll update it.

(In reply to Tom Tromey from comment #4)
> +gdb_test_no_output "maint expand-symtabs \\(pck\\|foo\\)\\.adb"

This turned out to be more complicated than I expected.

I managed to produce this in the end:
...
gdb_test_no_output {maint expand-symtabs "\(pck\|foo\)\.adb"}
...

The {} quotes prevent any TCL-level interpretation.

And the "" quotes prevent any buildargv-level interpretation, leaving '\(pck\|foo\)\.adb', which is the actual regexp used.

I managed to find out the regexp syntax by reading the implementation of re_comp in glibc.

https://sourceware.org/pipermail/gdb-patches/2024-September/211795.html

(In reply to Tom de Vries from comment #1)
> I found a way to reproduce this.
> 
> Pick a single cpu (say 7, an efficiency core), divide the boost frequency
> (3500Mhz) [1] by the base frequency (400Mhz): 8.75.  Round to 9.  Substract
> one and do:
> ...
> $ taskset -c 7 stress -c 8
> ...
> and run the test-case also using taskset -c 7.  That should cap the
> test-case to roughly the base frequency.
> 
> Using this approach, I can reproduce the timeout again.

This is an alternative solution: limit the entire system to 400Mhz:
...
$ for f in /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq; do echo $f; echo 400 | sudo tee $f; done
...

The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4a8a2d17999cd2b19cb568e240b208e94c428c8f

commit 4a8a2d17999cd2b19cb568e240b208e94c428c8f
Author: Tom de Vries <tdevries@suse.de>
Date:   Sat Sep 21 06:12:40 2024 +0200

    [gdb/testsuite] Fix timeout in gdb.ada/call_pn.exp
    
    With test-case gdb.ada/call_pn.exp and glibc debug info installed, I ran into
    this timeout:
    ...
    (gdb) maint expand-symtabs^M
    FAIL: gdb.ada/call_pn.exp: maint expand-symtabs (timeout)
    ...
    
    The timeout was related to running the cpu at base frequency of 400Mhz instead
    of boost frequency of 3.5Ghz (efficiency core) or 4.7Ghz (performance core).
    
    But when investigating the test-case I realized that the maint expand-symtabs
    could be limited to the source files, so use that to speed up the test-case.
    
    Tested on x86_64-linux.
    
    Co-Authored-By: Tom Tromey <tom@tromey.com>
    Approved-By: Tom Tromey <tom@tromey.com>
    
    PR testsuite/32177
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32177

Timeout in gdb.ada/call_pn.exp fixed.

Timeouts in gdb.ada/info_exc.exp and gdb.ada/mi_exc_info.exp handled in PR32182.