Re: [PATCH 4/5] gdb/testsuite: change newline patterns used in gdb_test

[Simon Marchi <simark@simark.ca>]

On 3/31/23 16:20, Andrew Burgess via Gdb-patches wrote:
> This commit makes two changes to how we match newline characters in
> the gdb_test proc.
> 
> First, for the newline pattern between the command output and the
> prompt, I propose changing from '[\r\n]+' to an explicit '\r\n'.
> 
> The old pattern would spot multiple newlines, and so there are a few
> places where, as part of this commit, I've needed to add an extra
> trailing '\r\n' to the pattern in the main test file, where GDB's
> output actually includes a blank line.
> 
> But I think this is a good thing.  If a command produces a blank line
> then we should be checking for it, the current test doesn't.
> 
> Additionally, the existing pattern will happily match a partial
> newline.  There are a strangely large number of tests that end with a
> random '.' character.  Not matching a literal period, but matching any
> single character, this is then matching half of the trailing newline
> sequence, while the \[\r\n\]+ in gdb_test is matching the other half
> of the sequence.  I can think of no reason why this would be
> intentional.  All of these are cleaned up after this commit.
> 
> The basic rule of gdb_test after this is that the expected pattern
> needs to match everything up to, but not including the newline
> sequence immediately before the GDB prompt.
> 
> Second, while I was cleaning up newline matching in gdb_test, I've
> also removed the '[\r\n]*' that was added to the start of the pattern
> passed to gdb_test_multiple.
> 
> The addition of this pattern adds no value.  If the user pattern
> matches at the start of a line then this would match against the
> newline sequence.  But, due to the '*', if the user pattern doesn't
> match at the start of a line then this group doesn't care, it'll
> happily match nothing.
> 
> As such, there's no value to it, it just adds more complexity for no
> gain, so I'm removing it.  No tests will need updating as a
> consequence of this part of the patch.

Hi Andrew,

Starting with this patch, I see many new failures in gdb.trace (using
one of the gdbserver boards), for instance the first one being:

  FAIL: gdb.trace/collection.exp: collect args collectively: collected arg char

Simon