[PATCH] [gdb/testsuite] Fix gdb.tui/resize-3.exp on ppc64-linux

[PATCH] [gdb/testsuite] Fix gdb.tui/resize-3.exp on ppc64-linux

[Tom de Vries]

On ppc64-linux, with test-case gdb.tui/resize-3.exp I run into:
...
FAIL: gdb.tui/resize-3.exp: after resize: Assembler for foo is shown
...
because the disassembly window shows:
...
    0 +----------------------------------------------------------------------+
    1 |   0x10000093c <.foo>                      std     r31,-8(r1)         |
    2 |   0x100000940 <.foo+4>                    stdu    r1,-64(r1)         |
    3 |   0x100000944 <.foo+8>                    mr      r31,r1             |
    4 |B+>0x100000948 <.foo+12>                   li      r9,0               |
...
and we grep for "<foo".

Fix this by updating the regexp.

Tested on ppc64-linux and x86_64-linux.
---
 gdb/testsuite/gdb.tui/resize-3.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.tui/resize-3.exp b/gdb/testsuite/gdb.tui/resize-3.exp
index fcda407c9fd..5a3d50aef48 100644
--- a/gdb/testsuite/gdb.tui/resize-3.exp
+++ b/gdb/testsuite/gdb.tui/resize-3.exp
@@ -69,5 +69,5 @@ with_test_prefix "after resize" {
 	"No Assembly message is not displayed" \
 	"No Assembly Available"
     Term::check_contents "Assembler for foo is shown" \
-	"$hex\\s+<foo"
+	[string cat $hex {\s+} "<" ([string_to_regexp .])? "foo"]
 }

base-commit: 0e4fd060ee7244d00c76f0d4815063dfcc9877f1
-- 
2.51.0

Re: [PATCH] [gdb/testsuite] Fix gdb.tui/resize-3.exp on ppc64-linux

[Tom Tromey]

Tom> -	"$hex\\s+<foo"
Tom> +	[string cat $hex {\s+} "<" ([string_to_regexp .])? "foo"]

Personally I find this a lot less readable than just writing out the
regular expression.

Tom

Re: [PATCH] [gdb/testsuite] Fix gdb.tui/resize-3.exp on ppc64-linux

[Tom de Vries]

On 10/17/25 4:14 PM, Tom Tromey wrote:
> Tom> -	"$hex\\s+<foo"
> Tom> +	[string cat $hex {\s+} "<" ([string_to_regexp .])? "foo"]
> 
> Personally I find this a lot less readable than just writing out the
> regular expression.

How about:
...
set re_dot [string_to_regexp "."]
set re [string cat $hex {\s+} "<" "($re_dot)?" "foo"]
...

Or:
...
set re [string cat $hex {\s+} "<" {(\.)?} "foo"]
...

I find this style much less readable:
...
set re "$hex\\s+<(\\.)?foo"
...

That is, I don't understand why you would join logically separate parts 
of the regexp together and force readers of the regexp to go through the 
process of separating them out again.

It's also error prone, especially where the dot is concerned:
- if you forget the second backslash on the s, you get a mismatch and
   it's easily spotted.
- if you forget the second backslash on the dot, you still get a match,
   but it'll match any character, say the a in "0x00c0ffee <afoo>".
I've seen many examples of this mistake in the testsuite sources.

Thanks,
- Tom

Re: [PATCH] [gdb/testsuite] Fix gdb.tui/resize-3.exp on ppc64-linux

[Tom de Vries]

On 10/18/25 10:21 AM, Tom de Vries wrote:
> On 10/17/25 4:14 PM, Tom Tromey wrote:
>> Tom> -    "$hex\\s+<foo"
>> Tom> +    [string cat $hex {\s+} "<" ([string_to_regexp .])? "foo"]
>>
>> Personally I find this a lot less readable than just writing out the
>> regular expression.
> 
> How about:
> ...
> set re_dot [string_to_regexp "."]
> set re [string cat $hex {\s+} "<" "($re_dot)?" "foo"]
> ...
> 
> Or:
> ...
> set re [string cat $hex {\s+} "<" {(\.)?} "foo"]
> ...
> 
Forgot to mention, a while back I proposed an extension to 
stringlist_to_regexp where using -re as an escape means don't use 
string_to_regexp because this part is already a regexp.

Using that method, we'd get:
...
set re \
     [stringlist_to_regexp \
         -re $hex -re {\s+} "<" -re "(" "." -re ")?" "foo"]
...

Thanks,
- Tom

Re: [PATCH] [gdb/testsuite] Fix gdb.tui/resize-3.exp on ppc64-linux

[Tom Tromey]

Tom> -	"$hex\\s+<foo"
Tom> +	[string cat $hex {\s+} "<" ([string_to_regexp .])? "foo"]

>> Personally I find this a lot less readable than just writing out the
>> regular expression.

Tom> I find this style much less readable:
Tom> ...
Tom> set re "$hex\\s+<(\\.)?foo"
Tom> ...

Tom> That is, I don't understand why you would join logically separate
Tom> parts of the regexp together and force readers of the regexp to go
Tom> through the process of separating them out again.

The specific reason I do find this more readable is that reading a
regular expression is a skill I already have, whereas decoding:

 [string cat $hex {\s+} "<" ([string_to_regexp .])? "foo"]

requires picking through each part and trying to understand what the
point is.

Tom> It's also error prone, especially where the dot is concerned:
Tom> - if you forget the second backslash on the s, you get a mismatch and
Tom>   it's easily spotted.
Tom> - if you forget the second backslash on the dot, you still get a match,
Tom>   but it'll match any character, say the a in "0x00c0ffee <afoo>".
Tom> I've seen many examples of this mistake in the testsuite sources.

This is not a mistake per se, I think.  Like, it isn't an instance of
someone being confused as to what to write and picking the wrong one.  I
think it is rather laziness about the quoting combined with the
recognition that it is hardly likely to matter.

Not that I'm supporting laziness in all cases, but a lot of times it
really just isn't important.

Like, in this case, if one wrote "<.?foo" would this really ever trigger
erroneously?  In your example above, where does "afoo" come from?  It
seems to me that a situation like that can be solved by picking more
distinct symbol names, something we've already had to do plenty of times
when it turns out that some C library happens to define the same symbol
name as a test case.

Another thought here is that regexps interact badly with Tcl double
quotes.  But they aren't as bad when using braces.  So maybe that's
another approach.

Just to ground this discussion a bit, I don't really care about this
particular test.  You can land this patch if you want.  I'm not likely
to ever look at it again.  However this is more about the future
direction of the test suite in general.  I would be against a more
global replacement of relatively straightforward (to me) regular
expressions with concatenations of function calls, not to mention
requiring this very wordy approach in patches.

Today I wrote a Tcl implementation of the "quotemeta" thing from the
AdaCore internal test suite.  We discussed it once before.  I'll attach
it to that bug.  It does help quite a bit (IMO) but unfortunately not
with the particular problem in this thread.

Tom

Re: [PATCH] [gdb/testsuite] Fix gdb.tui/resize-3.exp on ppc64-linux

[Tom de Vries]

On 10/18/25 7:19 PM, Tom Tromey wrote:
> Just to ground this discussion a bit, I don't really care about this
> particular test.  You can land this patch if you want.  I'm not likely
> to ever look at it again.  However this is more about the future
> direction of the test suite in general.

I ended up committing:

...
-	"$hex\\s+<foo"
+	[subst -nobackslashes -nocommands {$hex\s+<(\.)?foo}]
...

This means the entire string is using a single quoting style.  By using 
the braces, we get rid of the double escaping mess.   And by using 
subst, we still interpret the variable despite using braces.

I'm planning to submit a follow-up patch that introduces an alias 
subst_vars which would simplify this to:
...
+	[subst_vars {$hex\s+<(\.)?foo}]
...

Thanks,
- Tom