Hi!

On 2025-05-21 16:19, Tom de Vries wrote:
> On 5/19/25 15:23, Pedro Alves wrote:
>> I wrote a test like this:
>>
>>      gdb_test_multiple "command" "" -lbl {
>>         -re "^\r\nprefix foo(?=\r\n)" {
>>             exp_continue
>>         }
>>         -re "^\r\nprefix bar(?=\r\n)" {
>>             exp_continue
>>         }
>>         -re "^\r\prefix (?=\r\n)" {
> 
> Hi Pedro,
> 
> Missing n in "\r\n".
> 
>>             exp_continue
>>         }
>>         -re "^\r\n$::gdb_prompt $" {
>>                pass $gdb_test_name
>>         }
>>      }
>>
>> Anchors are needed in my case to avoid too-eager matching due to the
>> common prefix. 
> I'm not saying you don't need anchors, maybe you do or maybe you don't, but I don't understand how a common prefix is a reason to need one.
> 
> Also, if you need anchors, you need to match the command as well, so you need a -re "^command(?=\r\n)" clause.

Without anchors, then if the fake GDB outputs this:

	echo "prefix "
	echo "prefix foo"
	echo "prefix bar"
	echo "prefix "

and the expect buffer happens to contain at least:
 
  "prefix \r\nprefix foo\r\n"

... then the "prefix foo" pattern consumes the first "prefix " line inadvertently.

E.g., the version of the test that I'm attaching fails exactly like that, with:

(gdb) command
prefix 
prefix foo
prefix bar
prefix 
meant-to-be-matched-by-lbl-1
(gdb) <COMMAND>
<PREFIX-FOO>
<PREFIX-BAR>
<PREFIX>
<PROMPT>
PASS: gdb.testsuite/gdb-test-multiple.exp: command
PASS: gdb.testsuite/gdb-test-multiple.exp: $saw_command == 1
PASS: gdb.testsuite/gdb-test-multiple.exp: $saw_prompt == 1
FAIL: gdb.testsuite/gdb-test-multiple.exp: $saw_prefix == 2
PASS: gdb.testsuite/gdb-test-multiple.exp: $saw_prefix_foo == 1
PASS: gdb.testsuite/gdb-test-multiple.exp: $saw_prefix_bar == 1
saw_prompt: 1
saw_prefix: 1
saw_prefix_foo: 1
saw_prefix_bar: 1

This version is counting the matches, which notices that we only
saw "prefix" once, while we should have seen it twice.

That is patch #1 in the series I've attached.

> 
>> The intent is for the prompt match above to override the built-in
>> prompt match.  However, it doesn't and the test fails with output like
>> this:
>>
>>    (gdb) command
>>    prefix foo
>>    prefix bar
>>    meant-to-be-matched-by-lbl
>>    (gdb)
>>
>> That's because the built-in match for the prompt matches before the
>> -lbl pattern for this expect buffer:
>>
>>    \r\nmeant-to-be-matched-by-lbl\r\n(gdb)
>>
> 
> You can fix that by dropping the anchor and using "\r\n$::gdb_prompt $" instead.  Even more simple, use -wrap "".

That doesn't work properly.  See the commit logs of the patches I've attached.  The series is meant to show the
incremental results as we get to the final fully-passing testcase.  One of the steps adds a prompt match like that,
and the slightly tweaked testcase in the same patch fails.  Take a look at the commit logs of the patches, in
sequence, please.  It is easier to see it incrementally like that, I think.

> 
>> This this by anchoring the built-in prompt match if -lbl was
>> requested.
>>
> 
> This might be a good idea indeed.
> 
> FWIW, the intent of -lbl was to handle except buffers overflows, so the -lbl pattern is meant to match lines in absence of a prompt.

FYI, I needed this for an earlier version of the testcase in patch #44 of this series:

 https://inbox.sourceware.org/gdb-patches/20250519132308.3553663-45-pedro@palves.net/T/#u

That is doing "info threads", and extracting the output of every thread.  If you search
for ${common_prefix} in there, you'll find it.

I can't trigger the original issue with that version anymore without the gdb_test_multiple fix,
though, I think because the patterns in the current version consume all lines, so there's
no "meant-to-be-matched-by-lbl" anymore.  I guess I don't really need -lbl there anymore at all.

Still, this new testcase based on what yours does need it.  I can try to combine all of
this in a single patch, including the new testcase and a better description.  WDYT?

This idea of replacing GDB with a script is super interesting.  Did you consider writing that script
in tcl/expect, though?  Seems like it would be a perfect fit.  Read input, match against pattern, print
output.  :-P  Another alternative would be to write a bit of GDB python to register a new command, and
run the real GDB with that.  But a script like you came up with mocking GDB completely is nice, it's
very light and more decoupled.

> 
> But AFAIU, your patch will make matching more predictable, so that's a good thing.
> 
> I created a mockup test-case to emulate the case you describe above. I've left the anchoring in place for the prefix lines, but for the gdb output printed by gdb.sh, it doesn't look necessary. [ The test-case has hardcoded paths in it. ]

[ The version I attached does not hardcode paths any more. ]

Thanks,
Pedro Alves