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

Thanks,
- Tom