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

[Tom de Vries <tdevries@suse.de>]

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.

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