Re: [PATCH 13/17] btrace: non-stop

[Pedro Alves <palves@redhat.com>]

On 09/09/2015 01:20 PM, Metzger, Markus T wrote:
>> -----Original Message-----
>> From: Pedro Alves [mailto:palves@redhat.com]
>> Sent: Wednesday, September 9, 2015 1:54 PM
>> To: Metzger, Markus T
>> Cc: gdb-patches@sourceware.org
>> Subject: Re: [PATCH 13/17] btrace: non-stop
>>
>> On 09/09/2015 11:35 AM, Markus Metzger wrote:
>>
>>> +# make sure $line matches the full expected output per thread.
>>> +# and let's hope that GDB never mixes the output from different threads.
>>> +#
>>> +# this is quite fragile, mostly because the prompt appears somewhere in
>>> +# the middle of the output.
>>> +proc gdb_cont_to { threads cmd line nthreads } {
>>> +    global gdb_prompt
>>> +    set full_cmd "thread apply $threads $cmd"
>>> +    set prompt_seen 0
>>> +
>>> +    send_gdb "$full_cmd\n"
>>> +
>>> +    for {set i 0} {$i < $nthreads} {incr i} {
>>> +        set test "$full_cmd: thread $i"
>>> +
>>> +        # check for the prompt.  it may be in front of one of the lines we
>>> +        # try to match.
>>> +        gdb_test_multiple "" "$test: check prompt" {
>>> +            -notransfer -re "$gdb_prompt " {
>>> +                set prompt_seen 1
>>> +            }
>>> +        }
>>> +
>>
>> Hmmm.  I'm not sure I'm missing some subtlety, but it seems to me
>> that if you used -notransfer, then the prompt will still be in the buffer,
>> and ...
>>
>>> +        # check for the line.  and for a typical error.
>>> +        gdb_test_multiple "" $test {
>>> +            -re "Cannot execute this command \[^\\\r\\\n\]* is running\." {
>>> +                fail $test
>>> +            }
>>> +            -re "$line\[^\\\r\\\n\]*\r\n" {
>>> +                pass $test
>>> +            }
>>> +        }
>>
>> ... thus this gdb_test_multiple can trip on it and issue a fail.
> 
> As far as I understand expect, the above gdb_test_multiple would
> simply skip the $gdb_prompt at the beginning of the line.

Only if the buffer already holds enough data for the regex to match.
Expect reads data in chunks and puts it in the buffer, and then tries
a match.  If nothing matches, it fetches more data, and retries matching.
On an on, until a timeout.  So say $line is

[multi_line \
             "No more reverse-execution history\." \
             "\[^\\\r\\\n\]*" \
             "\[^\\\r\\\n\]*" \
            ]

It sometimes will happen that the expect buffer has:

 "$gdb_prompt\r\n...No more reverse-exe"

Because that doesn't match any of the regexs you have, gdb_test_multiple's
internal regex for the prompt matches, and issues a FAIL.
Try "make check-read1".  It may well be it catches this.

> 
> That's why I'm trying to detect it with a separate gdb_test_multiple
> above.  I use -notransfer so I can still analyse the line for the expected
> output.
> 
> 
>> Wouldn't this instead work?
>>
>>         gdb_test_multiple "" $test {
>>             -re "Cannot execute this command \[^\\\r\\\n\]* is running\." {
>>                 fail $test
>>             }
>>             -re "$line\[^\\\r\\\n\]*\r\n" {
>>                 pass $test
>>             }
>>             -re "$gdb_prompt " {
>>                 set prompt_seen 1
>>                 exp_continue
>>             }
>>        }
> 
> Wouldn't the 1st or 2nd pattern skip any $gdb_prompt before the pattern?

Yes.  Is that a problem?  Don't we always get another prompt after that error?

> For the "Cannot execute..." pattern, I could add "^" but this will be difficult
> for the $line pattern.
> 
> Does the 3rd pattern consume just the $gdb_prompt or the entire line?

Consumes everything up to the prompt.  Whatever follows is left in the buffer.

> This non-stop testing is quite difficult.  I also have not found too many
> examples when I searched for "non-stop".

Could you push the series to a branch somewhere?  The easiest would be
a users/ branch in the master repo.

Thanks,
Pedro Alves