[PATCH v2 00/42] Share DWARF partial symtabs between objfiles

Simon Marchi simark@simark.ca
Wed May 27 05:08:04 GMT 2020


On 2020-05-26 5:34 p.m., Simon Marchi wrote:
> On 2020-05-26 11:35 a.m., Simon Marchi wrote:
>> On 2020-05-26 7:17 a.m., Pedro Alves via Gdb-patches wrote:
>>> On 5/25/20 8:56 PM, Simon Marchi wrote:
>>>
>>>> Other than that, does any of you have further comments?  I've done the
>>>> small suggested fixups, but I don't think there was anything big
>>>> requiring another round, is there?
>>>
>>> No further comments from me.
>>>
>>> Thanks,
>>> Pedro Alves
>>>
>>
>> Ok, since I needed to do some non-trivial rebase, I'm giving it another round
>> of testing and I'll push it if it's all good.
>>
>> Simon
>>
> 
> Hmmm with the series applied, this triggers ASan:
> 
> $ make check TESTS="gdb.base/printcmds.exp" RUNTESTFLAGS="--target_board='cc-with-dwz-m'"
> 
> I still haven't found the issue, I'll have to check that later.

Ok, I think I have found the issue with this one.  Here's a brain dump before I go to bed
so I remember tomorrow:

- Things go wrong in this test because we load the same file twice
- Two objfiles representing the same binary are therefore created during the lifetime of GDB
- I noticed that some symbol belonging to the second objfile had a backlink to a symtab
  belonging to the first objfile
- The field dwarf_per_bfd::line_header_hash contains some "struct line_header" objects
- "struct line_header" contains "file_entry" objects, in its m_file_names field
- a "file_entry" object contains a pointer to the symtab that was created based on it
- If you go up the chain, it's then clear that file_entry and line_header are
  objfile-specific, so the field line_header_hash should not be in dwarf_per_bfd.

Simon




More information about the Gdb-patches mailing list