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

[tdevries <tdevries@suse.de>]

On 2022-12-19 13:52, Andrew Burgess via Gdb-patches wrote:
> 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.
> 

I also ran into this issue on ubuntu 22.04.1 x86_64.

AFAIK, the way we usually test for this type of information is "maint 
print objfile", which is less verbose, and doesn't have long lines.

Thanks,
- Tom

> Thanks,
> Andrew