On 29-03-2020 17:39, Simon Marchi wrote:
> On 2020-03-28 1:24 p.m., Tom de Vries wrote:
>>> 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
>>
> 
> Thanks, your explanations make more sense with the the DWARF in those files,
> I can reproduce the problem now.
> 
> I have a bit of trouble understanding the current code.  In particular, I am
> trying to put in words what's the difference between the `read_symtab` and
> `expand_symtab` methods of `partial_symtab`, but I can't quite do it.  I think
> this would help to determine what's the right solution.

Hi,

I gave that a try, but got stalled working on the test-case.

Anyway here's the current state.

Thanks,
- Tom