Re: [PATCH][gdb/testsuite] Make gdb.base/annota1.exp more robust

[Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>]

On 4/8/22 11:04, Tom de Vries wrote:
> On 4/7/22 20:38, Simon Marchi wrote:
>> On 2022-04-05 09:47, Tom de Vries via Gdb-patches wrote:
>>> Hi,
>>>
>>> On openSUSE Tumbleweed I run into:
>>> ...
>>> FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
>>> ...
>>>
>>> The problem is that the libthread_db message occurs at a location 
>>> where it's
>>> not expected:
>>> ...
>>> Starting program: outputs/gdb.base/annota1/annota1 ^M
>>> ^M
>>> ^Z^Zstarting^M
>>> ^M
>>> ^Z^Zframes-invalid^M
>>> [Thread debugging using libthread_db enabled]^M
>>> Using host libthread_db library "/lib64/libthread_db.so.1".^M
>>> ^M
>>> ^Z^Zbreakpoints-invalid^M
>>> ^M
>>> ...
>>>
>>> Fix this by making the matching more robust:
>>> - rewrite the regexp such that each annotation is on a single line,
>>>    starting with \r\n\032\032 and ending with \r\n
>>> - add a regexp variable optional_re, that matches all possible optional
>>>    output, and use it as a separator in the first part of the regexp
>>>
>>> Tested on x86_64-linux.
>>>
>>> Any comments?
>>>
>>> Thanks,
>>> - Tom
>>
>> Hi Tom,
>>
>> This introduces a failure on Ubuntu 20.04 and on Arch Linux.
>>
>>      PASS: gdb.base/annota1.exp: breakpoint info
>>      run^M
>>      ^M
>>      ^Z^Zpost-prompt^M
>>      Starting program: 
>> /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/annota1/annota1 
>> ^M
>>      ^M
>>      ^Z^Zbreakpoints-invalid^M
>>      ^M
>>      ^Z^Zstarting^M
>>      ^M
>>      ^Z^Zframes-invalid^M
>>      ^M
>>      ^Z^Zbreakpoints-invalid^M
>>      ^M
>>      ^Z^Zbreakpoint 1^M
>>      ^M
>>      Breakpoint 1, ^M
>>      ^Z^Zframe-begin 0 0x555555555183^M
>>      ^M
>>      ^Z^Zframe-function-name^M
>>      main^M
>>      ^Z^Zframe-args^M
>>       ()^M
>>      ^Z^Zframe-source-begin^M
>>       at ^M
>>      ^Z^Zframe-source-file^M
>>      /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/annota1.c^M
>>      ^Z^Zframe-source-file-end^M
>>      :^M
>>      ^Z^Zframe-source-line^M
>>      15^M
>>      ^Z^Zframe-source-end^M
>>      ^M
>>      ^M
>>      ^Z^Zsource 
>> /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/annota1.c:15:103:beg:0x555555555183^M 
>>
>>      ^M
>>      ^Z^Zframe-end^M
>>      ^M
>>      ^Z^Zstopped^M
>>      ^M
>>      ^Z^Zpre-prompt^M
>>      (gdb) ^M
>>      ^Z^Zprompt^M
>>      FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
>>
>> The issue is the now hardcoded order of "breakpoints-invalid" and
>> "frames-invalid" order in the test regexp, where the output happens in
>> the other order.  Before your change, we had:
>>
>>      
>> "\(\(\r\n\r\n\032\032frames-invalid\)|\(\r\n\r\n\032\032breakpoints-invalid\)\)*\r\n\r\n" 
>> \
>>
>> Meaning we didn't care about the order of those, and we didn't care if
>> we saw them or not.  The change below moves those lines in optional_re,
>> and fixes things on my side.
>>
> 
> Hi Simon,
> 
> thanks for reporting this.
> 
> I managed to reproduce on openSUSE Leap 15.3 with target board 
> unix/-pie/-fPIE, and on ubuntu 20.04.
> 
> AFAICT, the issue is not a different order, but an additional 
> annotation, and looking at the log you've posted above, I see the same.
> 
> I've wrote attached patch which fixes it, I've tested on both openSUSE 
> and Ubuntu.
> 
> WDYT?

Pushed, but now that I reply here I see I didn't fully read the 
rationale for the patch you posted, and didn't follow up on that, 
apologies for that.

So, perhaps you're right, perhaps we don't care about the order (though 
it would be nice for me to understand why we don't care).

I understood the matching in the test-case to be very loose due to 
having to juggle mostly the variance in non-annotation output.  So I 
decided to "fix" this by being as strict as possible in matching 
annotations, and as simple as possible in matching non-annotations.

I hope the committed patch will be sufficient though.

I you think there's still an issue, then I can revert and apply your patch.

Thanks,
- Tom