Re: [PATCH 2/2] gdb/testsuite: new test for recent dwarf reader issue

[Andrew Burgess <aburgess@redhat.com>]

Luis Machado <luis.machado@arm.com> writes:

> On 12/15/22 11:22, Andrew Burgess wrote:
>> Luis Machado <luis.machado@arm.com> writes:
>> 
>>> Hi Andrew,
>>>
>>> On 12/9/22 19:24, Andrew Burgess via Gdb-patches wrote:
>>>> Tom Tromey <tom@tromey.com> writes:
>>>>
>>>>>>>>>> "Andrew" == Andrew Burgess via Gdb-patches <gdb-patches@sourceware.org> writes:
>>>>>
>>>>> Thank you for doing this.
>>>>>
>>>>> Andrew>   - However, GDB checks each partial symbol using multiple languages,
>>>>> Andrew>     not just the current language (C in this case), so, when GDB
>>>>> Andrew>     checks using the C++ language, the symbol name is first demangled,
>>>>> Andrew>     the code that does this can be found
>>>>> Andrew>     lookup_name_info::language_lookup_name.  As the demangled form of
>>>>> Andrew>     'signed int' is just 'int', GDB then looks for any symbols with
>>>>> Andrew>     the name 'int', most partial symtabs will contain such a symbol,
>>>>> Andrew>     so GDB ends up expanding pretty much every symtab.
>>>>>
>>>>> It's a pedantic point but what happens here is name canonicalization,
>>>>> not demangling.  Demangling is just used to refer to the translation
>>>>> from a name like "_Zmumble" to "something::else" -- that is, the input
>>>>> is a linkage name and the output is a C++ name.  Canonicalization takes
>>>>> a C++ name as input and returns the standard form, basically dealing
>>>>> with the fact that C++ (and as we discovered, C) has multiple possible
>>>>> spellings for some symbols.
>>>>
>>>> Please, be pedantic.  My goal here was to better understand this code,
>>>> there's no point me understanding it wrong.
>>>>
>>>> I'll reword that paragraph.
>>>>
>>>> Thanks for taking a look.
>>>>
>>>> Andrew
>>>>
>>>
>>> I'm not saying you should investigate this, as it is a new test, but I'm getting a lot of these messages for this test:
>>>
>>> ERROR: internal buffer is full.
>> 
>> Happy to take a look at the problem.
>> 
>> I guess the issue is coming from the gdb_test_multiple that I use in the
>> new test script.
>> 
>> I'm tried to write patterns that match and discard all the lines as they
>> arrive from GDB.  I guess you are seeing a pattern that I am not for
>> some reason.
>> 
>> Could you run just this test and attach the gdb.log file and I'll take a
>> look.  I probably just need to tweak one of the patterns a little.
>> 
>> Thanks,
>> Andrew
>> 
>
> I briefly looked into this. The problem seems to arise from the fact that sometimes we don't have multiple lines for the "info sources" output.
>
> Some sections are output in a single line. For example, one of them has 133K characters. But each entry seems to be separated by a comma character:
>
> ./elf/./elf/rtld.c, ./elf/../include/rtld-malloc.h, ./elf/../sysdeps/generic/ldsodefs.h, ./elf/../sysdeps/aarch64/dl-machine.h, ...

Ahh, that would explain it.  We don't appear to use 'info sources' that
frequently in the testsuite.  I wonder if you are also seeing failures
on those other tests?

  gdb.asm/asm-source.exp
  gdb.dwarf2/dup-psym.exp
  gdb.dwarf2/dw2-filename.exp

> It might be best (for the testsuite) if gdb outputs this data across more lines.

The other option might be to extend 'info sources' to allow filtering
based on the objfile name, then we can use this in the testsuite to
limit the output...

... or I wonder if we could trick GDB by setting the width to something
small, the I guess the lines would be broken after the ',' characters.

I'll have a play and see what I can come up with.

Thanks,
Andrew