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

[Andrew Burgess <aburgess@redhat.com>]

tdevries <tdevries@suse.de> writes:

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

I'm looking at this issue today, I'll give 'maint print objfile' a go.
Thanks for the suggestion.

Thanks,
Andrew