What made me suspect a data corruption issue were asserts triggered in the VC++ 
vector implementation when we use an LTO binary with a DEBUG lldb build on 
Windows.

   For example, 
   at source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp:624,

   File: C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\vector
   Line: 240
   Expression: vector iterators incompatible
 
Digging deeper, the assertion is triggered by accesses to 
DWARFCompileUnit::m_die_array 

In the 'parser_fn' lambda in SymbolFileDWARF::Index() that indexes each compile 
unit in parallel, DWARFCompileUnit::ExtractDIEsIfNeeded(..) , 
DWARFCompileUnit::Index(..) and DWARFCompileUnit::ClearDIEs() are called in 
sequence.

'ExtractDIEsIfNeeded' and 'ClearDIEs' respectively populates and clears 
DWARFCompileUnit::m_die_array.

But when DWARFCompileUnit::Index(..) looks up a DIE in another CU and that CU 
is running 'ExtractDIEsIfNeeded' or 'ClearDIEs', it will access a stale or 
invalid DWARFCompileUnit::m_die_array ...

-Philippe

________________________________________
From: Greg Clayton [gclay...@apple.com]
Sent: Monday, April 25, 2016 7:59 PM
To: Philippe Lavoie
Cc: lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] LTO debug info

> On Apr 25, 2016, at 1:37 PM, Philippe Lavoie via lldb-dev 
> <lldb-dev@lists.llvm.org> wrote:
>
> Hello,
>
> We noticed an issue with dwarf parsing when debugging a large application 
> compiled with LTO.
>
> Since an LTO application's debug info can have inter-compile-unit references, 
> (for example: a type defined in one compile-unit and used in another) we 
> noticed that the "m_type_index" vector in SymbolFileDWARF can get corrupted. 
> This is because many index structures in SymbolFileDWARF are generated in 
> parallel.
>
> Is is a bug or is it expected to be the compiler's/linker's job to generate 
> self-contained DWARF data without inter-CU references?
>
> -Philippe

TEach SymbolFileDWARF should generate its own accelerator tables in a self 
contained way. No SymbolFileDWARF should be adding references to their 
accelerator maps that actually refer to DIEs from another SymbolFileDWARF. We 
might need to look at the indexing function that make sure if they see and 
DW_FORM_ref_addr attributes, that they don't add any of them to their index. 
That seems like the bug?

Greg

_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to