Re: [PATCH][gdb] Fix missing symtab includes

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

On 28-03-2020 17:32, Simon Marchi wrote:
> On 2020-03-27 4:49 p.m., Tom de Vries wrote:
>> Hi,
>>
>> Consider hello.h:
>> ...
>>  inline static const char*
>>  foo (void)
>>  {
>>    return "foo";
>>  }
>> ...
>> and hello.c:
>> ...
>>  #include <stdio.h>
>>  #include "hello.h"
>>
>>  int
>>  main (void)
>>  {
>>    printf ("hello: %s\n", foo ());
>>    return 0;
>>  }
>> ...
>> compiled with -g, and dwz-compressed:
>> ...
>> $ gcc -g hello.c
>> $ dwz a.out
>> ...
>>
>> When breaking on foo and printing the symbol tables, we have two includes for
>> the hello.c compunit_symtab, representing two imported partial units:
>> ...
>> $ gdb -iex "set language c" -batch a.out -ex "b foo" -ex "maint info symtabs"
>> Breakpoint 1 at 0x40050b: file hello.h, line 4.
>>   ...
>>   { ((struct compunit_symtab *) 0x38fa890)
>>     debugformat DWARF 2
>>     producer GNU C11 7.5.0 -mtune=generic -march=x86-64 -g
>>     dirname /data/gdb_versions/devel
>>     blockvector ((struct blockvector *) 0x39af9f0)
>>     user ((struct compunit_symtab *) (null))
>>     ( includes
>>       ((struct compunit_symtab *) 0x39afb10)
>>       ((struct compunit_symtab *) 0x39b00c0)
>>     )
>>         { symtab hello.c ((struct symtab *) 0x38fa940)
>>           fullname (null)
>>           linetable ((struct linetable *) 0x39afa80)
>>         }
>> ...
> 
> I am not able to reproduce this.  In both cases, I don't get the `includes`.
> 
> What transformation is dwz expected to do on the binary?  Here, it looks like
> it just compressed the debug info a little bit, changing the addresses, but the
> general structure was untouched.
> 
> I'm using the latest git version of dwz (commit b7111689a2ccec2f57343f1051ec8f1df5e89e5c).

Hi Simon,

thanks for trying this out.

I've attached the original a.out here (
https://sourceware.org/bugzilla/show_bug.cgi?id=25718#c3 ) and the
dwz-ed a.out here (
https://sourceware.org/bugzilla/show_bug.cgi?id=25718#c4  ).

I'm hoping you might be able to reproduce using the latter file (and
FWIW, I'm using the same dwz version).

I think the reason for the difference in what we are seeing is due to me
using openSUSE, which has debug info on various linked in objects like
glibc's init.c and elf-init.c. Looking at the readelf -wi output of the
dwz-ed executable, dwz exploits commonality between those objects and
hello.c, so it's not surprising dwz does not create partial units for
platforms that do not have debug info for those objects.

Anyway, I'll need to construct a better test-case that reproduces the
problem on other platforms.

Thanks,
- Tom