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.

> 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 "".

> 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.

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. ]

Thanks,
- Tom