Re: [RFC PATCH] gdb/testsuite: fix gdb.base/info-types*.exp when no libc debug info

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Tom de Vries <tdevries@suse.de> [2021-06-23 14:04:54 +0200]:

> On 6/22/21 11:52 PM, Andrew Burgess wrote:
> > * Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> [2021-06-22 13:24:47 -0400]:
> > 
> >> On Ubuntu 20.04, when the debug info package for libc is not installed,
> >> I get:
> >>
> >>     FAIL: gdb.base/info-types-c++.exp: info types
> >>     FAIL: gdb.base/info-types-c.exp: info types
> >>
> >> The reason is that the output of info types is exactly:
> >>
> >>     (gdb) info types
> >>     All defined types:
> >>
> >>     File /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/info-types.c:
> >>     52:     typedef enum {...} anon_enum_t;
> >>     45:     typedef struct {...} anon_struct_t;
> >>     68:     typedef union {...} anon_union_t;
> >>     28:     typedef struct baz_t baz;
> >>     31:     typedef struct baz_t * baz_ptr;
> >>     21:     struct baz_t;
> >>             double
> >>     33:     enum enum_t;
> >>             float
> >>             int
> >>     38:     typedef enum enum_t my_enum_t;
> >>     17:     typedef float my_float_t;
> >>     16:     typedef int my_int_t;
> >>     54:     typedef enum {...} nested_anon_enum_t;
> >>     47:     typedef struct {...} nested_anon_struct_t;
> >>     70:     typedef union {...} nested_anon_union_t;
> >>     30:     typedef struct baz_t nested_baz;
> >>     29:     typedef struct baz_t nested_baz_t;
> >>     39:     typedef enum enum_t nested_enum_t;
> >>     19:     typedef float nested_float_t;
> >>     18:     typedef int nested_int_t;
> >>     62:     typedef union union_t nested_union_t;
> >>     56:     union union_t;
> >>             unsigned int
> >>     (gdb)
> >>
> >> The lines we expect in the test contain an empty line at the end:
> >>
> >>     ...
> >>     "18:\[\t \]+typedef int nested_int_t;" \
> >>     "62:\[\t \]+typedef union_t nested_union_t;" \
> >>     "--optional" "\[\t \]+unsigned int" \
> >>     ""]
> >>
> >> This is written with the supposition that other files will be listed, so
> >> an empty line will be included to separate the symbols from this file
> >> from the next one.  This empty line is not included when info-types.c is
> >> the only file listed.
> >>
> >> This patch fixes the issue by not requiring an empty line.  I don't
> >> think it's a very good solution, however: the empty line ensures that
> >> there is no additional unexpected items after "unsigned int".
> >>
> >> I don't think that making the empty line optional (with --optional)
> >> would achieve anything, since the lines would still match if there was
> >> some unexpected output.
> >>
> >> So, I'll think about it a bit more, but any suggestions are appreciated.
> > 
> > What about the patch below?  Instead of using the builtin
> > gdb_test_lines, I grab the type lines (but just for $srcfile) using
> > gdb_test_multiple, then manually check for each type in turn.
> > 
> > We no longer care about the order of the types in the output, but I
> > think that is fine, the order was always pretty random anyway.
> > 
> 
> I'm curious, could you elaborate on this?  In what situations did you
> see a different order?
> 
> [ Not that I much mind not matching in order, it doesn't look terribly
> important to me. ]

I didn't, see my follow up email.

> 
> Anyway, I have a minor concern about this patch: that it is a local,
> specific solution.  Ideally we specify some matching data that is
> specific to the test-case, and pass it to a lib/gdb.exp proc, which is
> generic enough to handle similar cases.

I'm happy with your approach.  I'd already posted my follow up before
your email arrived my end.

Thanks,
Andrew