[committed][gdb/testsuite] Fix FAIL in gdb.mi/mi-var-child-f.exp

Tom de Vries tdevries@suse.de
Tue Oct 12 12:28:56 GMT 2021


On 10/11/21 5:00 PM, Tom de Vries via Gdb-patches wrote:
> Hi,
> 
> When running test-case gdb.mi/mi-var-child-f.exp on openSUSE Tumbleweed
> (with glibc 2.34) I run into:
> ...
> (gdb) ^M
> PASS: gdb.mi/mi-var-child-f.exp: mi runto prog_array
> Expecting: ^(-var-create array \* array[^M
> ]+)?(\^done,name="array",numchild="[0-9]+",value=".*",type=.*,has_more="0"[^M
> ]+[(]gdb[)] ^M
> [ ]*)
> -var-create array * array^M
> &"Attempt to use a type name as an expression.\n"^M
> ^error,msg="-var-create: unable to create variable object"^M
> (gdb) ^M
> FAIL: gdb.mi/mi-var-child-f.exp: create local variable array (unexpected output)
> ...
> 
> The problem is that the name array is used both:
> - as the name for a local variable
> - as the name of a type in glibc, in file malloc/dynarray-skeleton.c, as included
>   by nss/nss_files/files-hosts.c.
> 
> Fix this by ignoring the shared lib symbols.
> 
> Likewise in a couple of other fortran tests.
> 
> Tested on x86_64-linux.
> 
> Committed to trunk.

Hmm, I just found https://bugzilla.redhat.com/show_bug.cgi?id=2012976
PR2012976 - "GDB's Fortran lexical analyzer can mis-categorize symbol
tokens" which indicates that this is a symptom of an actual problem.

Anyway, I don't think it's useful to revert the committed patch since
there's no point in having this particular problem showing up in
hundreds of FAILs.

Thanks,
- Tom


More information about the Gdb-patches mailing list