[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