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

[Luis Machado <luis.machado@arm.com>]

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, ...

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