[ was: Re: [PATCH][gdb] Expand symbolless symtabs using maint
expand-symtabs ]

On 14-04-2020 15:09, Tom de Vries wrote:
> On 02-04-2020 10:44, Tom de Vries wrote:
>> On 01-04-2020 21:45, Tom Tromey wrote:
>>>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
>>>
>>> Tom> When trying to expand the partial symtab for hello.h:
>>> Tom> ...
>>> Tom> $ gdb -batch \
>>> Tom>   -iex "set language c" \
>>> Tom>   a.out \
>>> Tom>   -ex "maint expand-symtabs hello.h" \
>>> Tom>   -ex "maint info psymtabs"
>>> Tom> ...
>>> Tom> we in fact find that the partial symtab has not been expanded:
>>> Tom> ...
>>> Tom>   { psymtab hello.h ((struct partial_symtab *) 0x27cf070)
>>> Tom>     readin no
>>> Tom> ...
>>>
>>> Does this matter, though?
>>> I thought include psymtabs like these were kind of placeholders.
>>>
>>
>> Right, but the includer symtab they're pointing towards are also not
>> expanded.
>>
> 
> I've updated the log message to reflect this, as well as the test-case.
> 
>> Concretely, it does matter for dwarf assembly test-cases, in the sense
>> that this patch allows me to have the symtab effect of setting a
>> breakpoint in a certain file, without actually setting the breakpoint,
>> which means there's no need to flesh out the .debug_line section in
>> detail, or indeed even create the file.
>>
>> [ I mentioned this patch as a prerequisite for a dwarf assembly
>> test-case here :
>> https://sourceware.org/pipermail/gdb-patches/2020-March/167152.html ]
>>
>> Furthermore, I found this problem originally not with include psymtabs,
>> but with this type of one-DIE CUs:
>> ...
>>  <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
>>     <c>   DW_AT_stmt_list   : 0x0
>>     <10>   DW_AT_low_pc      : 0x400430
>>     <18>   DW_AT_high_pc     : 0x40045b
>>     <20>   DW_AT_name        : ../sysdeps/x86_64/start.S
>>     <24>   DW_AT_comp_dir    : /home/abuild/rpmbuild/BUILD/glibc-2.26/csu
>>     <28>   DW_AT_producer    : GNU AS 2.31.1
>>     <2c>   DW_AT_language    : 32769    (MIPS assembler)
>> ...
>> which I get in every exec on openSUSE Leap 15.1.
>>
>> In that case, the problem means that "maint expand-symtabs" doesn't
>> expand the symtab, in violation of the "maint expand-symtabs"
>> documentation, while also being inconsistent with -readnow which does
>> create a symbolless symtab.
>>
> 
> I've also noted this in the log message.
> 
>> I used the include psymtabs as test-case and running example because it
>> reproduces on all platforms in a standard test-case.
>>
>>> Tom> Fix this by passing a NULL symbol_matcher and lookup_name to
>>> Tom> expand_symtabs_matching in maintenance_expand_symtabs, and skipping the call
>>> Tom> to recursively_search_psymtabs if symbol_matcher == NULL and
>>> Tom> lookup_name == NULL.
>>>
>>> Could this code use map_symtabs_matching_filename instead?
>>>
>>
>> I can see how that would help with "maint expand-symtabs <file>", but
>> still "maint expand-symtabs" would not expand the partial symtab for
>> ../sysdeps/x86_64/start.S.
>>
>> Thanks,
>> - Tom
>>
>>> I guess I'm not super fond of turning the reference arguments to
>>> pointers, unless there's really no other way.
> 
> Unfortunately I don't see another way atm, so I'm committing this as
> attached below.
> 
> [ FWIW, something I'm not very happy with myself is the undoing of the
> micro-optimization of having this outside of the partial symtabs loop:
> ...
>   lookup_name_info lookup_name = lookup_name_in.make_ignore_params ();
> ...
> but I'm not sure how to address that. ]

I somehow forgot the logic behind manually setting the language and how
that is related to indices, so in the committed version I removed the
manual language setting, and did not retest with cc-with-gdb-index, with
a FAIL as result.

This patch fixes that by reinstating the manual language setting.

Committed.

Thanks,
- Tom