[Lldb-commits] [PATCH] D131437: Don't index the skeleton CU when we have a fission compile unit.

2022-09-13 Thread Jordan Rupprecht via Phabricator via lldb-commits 
rupprecht added a comment.

In D131437#3751366 , @bkramer wrote:

> This seems to trigger a use after free in `lldb-api :: 
> functionalities/thread/create_after_attach/TestCreateAfterAttach.py`
>
> asan log:
>
>   ==4741==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x62f00023bf58 at pc 0x563639db88f1 bp 0x7ffd942412f0 sp 0x7ffd942412e8
>   READ of size 4 at 0x62f00023bf58 thread T0
>   #0 0x563639db88f0 in HasChildren 
> lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.h:124:37
>   #1 0x563639db88f0 in GetFirstChild 
> lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.h:148:12
>   #2 0x563639db88f0 in GetFirstChild 
> lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp:101:34
>   #3 0x563639db88f0 in child_iterator 
> lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.h:107:57
>   #4 0x563639db88f0 in DWARFDIE::children() const 
> lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp:466:27
>   #5 0x563639d9f4e1 in 
> DWARFASTParserClang::EnsureAllDIEsInDeclContextHaveBeenParsed(lldb_private::CompilerDeclContext)
>  lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2203:37
>   #6 0x563639f1ab62 in 
> lldb_private::TypeSystemClang::DeclContextFindDeclByName(void*, 
> lldb_private::ConstString, bool) 
> lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:9494:22
>   #7 0x563639f489fd in 
> lldb_private::CompilerDeclContext::FindDeclByName(lldb_private::ConstString, 
> bool) lldb/source/Symbol/CompilerDeclContext.cpp:20:27
>   #8 0x563639b6113c in 
> lldb_private::ClangExpressionDeclMap::LookupLocalVariable(lldb_private::NameSearchContext&,
>  lldb_private::ConstString, lldb_private::SymbolContext&, 
> lldb_private::CompilerDeclContext const&) 
> lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:1084:20
>   #9 0x563639b5d7cf in 
> lldb_private::ClangExpressionDeclMap::FindExternalVisibleDecls(lldb_private::NameSearchContext&,
>  std::__u::shared_ptr, 
> lldb_private::CompilerDeclContext const&) 
> lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:1434:9
>   #10 0x563639b5c9df in 
> lldb_private::ClangExpressionDeclMap::FindExternalVisibleDecls(lldb_private::NameSearchContext&)
>  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:728:5
>   #11 0x563639b3df83 in 
> lldb_private::ClangASTSource::FindExternalVisibleDeclsByName(clang::DeclContext
>  const*, clang::DeclarationName) 
> lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp:180:3
>   #12 0x56363d02aa30 in 
> clang::DeclContext::lookup(clang::DeclarationName) const 
> clang/lib/AST/DeclBase.cpp:1706:17
>   #13 0x56363c2bca5b in LookupDirect(clang::Sema&, clang::LookupResult&, 
> clang::DeclContext const*) clang/lib/Sema/SemaLookup.cpp:1108:39
>   #14 0x56363c2b67f5 in CppNamespaceLookup(clang::Sema&, 
> clang::LookupResult&, clang::ASTContext&, clang::DeclContext*, (anonymous 
> namespace)::UnqualUsingDirectiveSet&) clang/lib/Sema/SemaLookup.cpp:1207:16
>   #15 0x56363c2b5a1e in clang::Sema::CppLookupName(clang::LookupResult&, 
> clang::Scope*) clang/lib/Sema/SemaLookup.cpp:1495:15
>   #16 0x56363c2bc0f2 in clang::Sema::LookupName(clang::LookupResult&, 
> clang::Scope*, bool, bool) clang/lib/Sema/SemaLookup.cpp:2259:9
>   #17 0x56363bdb50b8 in clang::Sema::BuildUsingDeclaration(clang::Scope*, 
> clang::AccessSpecifier, clang::SourceLocation, bool, clang::SourceLocation, 
> clang::CXXScopeSpec&, clang::DeclarationNameInfo, clang::SourceLocation, 
> clang::ParsedAttributesView const&, bool, bool) 
> clang/lib/Sema/SemaDeclCXX.cpp:12329:5
>   #18 0x56363bdb49f3 in clang::Sema::ActOnUsingDeclaration(clang::Scope*, 
> clang::AccessSpecifier, clang::SourceLocation, clang::SourceLocation, 
> clang::CXXScopeSpec&, clang::UnqualifiedId&, clang::SourceLocation, 
> clang::ParsedAttributesView const&) clang/lib/Sema/SemaDeclCXX.cpp:11833:7
>   #19 0x56363b49df12 in 
> clang::Parser::ParseUsingDeclaration(clang::DeclaratorContext, 
> clang::Parser::ParsedTemplateInfo const&, clang::SourceLocation, 
> clang::SourceLocation&, clang::ParsedAttributes&, clang::AccessSpecifier) 
> clang/lib/Parse/ParseDeclCXX.cpp:803:26
>   #20 0x56363b49c27d in 
> clang::Parser::ParseUsingDirectiveOrDeclaration(clang::DeclaratorContext, 
> clang::Parser::ParsedTemplateInfo const&, clang::SourceLocation&, 
> clang::ParsedAttributes&) clang/lib/Parse/ParseDeclCXX.cpp:512:10
>   #21 0x56363b46c161 in 
> clang::Parser::ParseDeclaration(clang::DeclaratorContext, 
> clang::SourceLocation&, clang::ParsedAttributes&, clang::ParsedAttributes&, 
> clang::SourceLocation*) clang/lib/Parse/ParseDecl.cpp:1797:12
>   #22 0x56363b55fb99 in 
> clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector  32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, 
> clang::ParsedAttributes&, clang::ParsedAttributes&) 
> clang/lib/Parse/ParseStmt.cpp

[Lldb-commits] [PATCH] D131437: Don't index the skeleton CU when we have a fission compile unit.

2022-08-26 Thread Benjamin Kramer via Phabricator via lldb-commits 
bkramer added a comment.

This seems to trigger a use after free in `lldb-api :: 
functionalities/thread/create_after_attach/TestCreateAfterAttach.py`

asan log:

  ==4741==ERROR: AddressSanitizer: heap-use-after-free on address 
0x62f00023bf58 at pc 0x563639db88f1 bp 0x7ffd942412f0 sp 0x7ffd942412e8
  READ of size 4 at 0x62f00023bf58 thread T0
  #0 0x563639db88f0 in HasChildren 
lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.h:124:37
  #1 0x563639db88f0 in GetFirstChild 
lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.h:148:12
  #2 0x563639db88f0 in GetFirstChild 
lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp:101:34
  #3 0x563639db88f0 in child_iterator 
lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.h:107:57
  #4 0x563639db88f0 in DWARFDIE::children() const 
lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp:466:27
  #5 0x563639d9f4e1 in 
DWARFASTParserClang::EnsureAllDIEsInDeclContextHaveBeenParsed(lldb_private::CompilerDeclContext)
 lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:2203:37
  #6 0x563639f1ab62 in 
lldb_private::TypeSystemClang::DeclContextFindDeclByName(void*, 
lldb_private::ConstString, bool) 
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:9494:22
  #7 0x563639f489fd in 
lldb_private::CompilerDeclContext::FindDeclByName(lldb_private::ConstString, 
bool) lldb/source/Symbol/CompilerDeclContext.cpp:20:27
  #8 0x563639b6113c in 
lldb_private::ClangExpressionDeclMap::LookupLocalVariable(lldb_private::NameSearchContext&,
 lldb_private::ConstString, lldb_private::SymbolContext&, 
lldb_private::CompilerDeclContext const&) 
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:1084:20
  #9 0x563639b5d7cf in 
lldb_private::ClangExpressionDeclMap::FindExternalVisibleDecls(lldb_private::NameSearchContext&,
 std::__u::shared_ptr, lldb_private::CompilerDeclContext 
const&) 
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:1434:9
  #10 0x563639b5c9df in 
lldb_private::ClangExpressionDeclMap::FindExternalVisibleDecls(lldb_private::NameSearchContext&)
 lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:728:5
  #11 0x563639b3df83 in 
lldb_private::ClangASTSource::FindExternalVisibleDeclsByName(clang::DeclContext 
const*, clang::DeclarationName) 
lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp:180:3
  #12 0x56363d02aa30 in clang::DeclContext::lookup(clang::DeclarationName) 
const clang/lib/AST/DeclBase.cpp:1706:17
  #13 0x56363c2bca5b in LookupDirect(clang::Sema&, clang::LookupResult&, 
clang::DeclContext const*) clang/lib/Sema/SemaLookup.cpp:1108:39
  #14 0x56363c2b67f5 in CppNamespaceLookup(clang::Sema&, 
clang::LookupResult&, clang::ASTContext&, clang::DeclContext*, (anonymous 
namespace)::UnqualUsingDirectiveSet&) clang/lib/Sema/SemaLookup.cpp:1207:16
  #15 0x56363c2b5a1e in clang::Sema::CppLookupName(clang::LookupResult&, 
clang::Scope*) clang/lib/Sema/SemaLookup.cpp:1495:15
  #16 0x56363c2bc0f2 in clang::Sema::LookupName(clang::LookupResult&, 
clang::Scope*, bool, bool) clang/lib/Sema/SemaLookup.cpp:2259:9
  #17 0x56363bdb50b8 in clang::Sema::BuildUsingDeclaration(clang::Scope*, 
clang::AccessSpecifier, clang::SourceLocation, bool, clang::SourceLocation, 
clang::CXXScopeSpec&, clang::DeclarationNameInfo, clang::SourceLocation, 
clang::ParsedAttributesView const&, bool, bool) 
clang/lib/Sema/SemaDeclCXX.cpp:12329:5
  #18 0x56363bdb49f3 in clang::Sema::ActOnUsingDeclaration(clang::Scope*, 
clang::AccessSpecifier, clang::SourceLocation, clang::SourceLocation, 
clang::CXXScopeSpec&, clang::UnqualifiedId&, clang::SourceLocation, 
clang::ParsedAttributesView const&) clang/lib/Sema/SemaDeclCXX.cpp:11833:7
  #19 0x56363b49df12 in 
clang::Parser::ParseUsingDeclaration(clang::DeclaratorContext, 
clang::Parser::ParsedTemplateInfo const&, clang::SourceLocation, 
clang::SourceLocation&, clang::ParsedAttributes&, clang::AccessSpecifier) 
clang/lib/Parse/ParseDeclCXX.cpp:803:26
  #20 0x56363b49c27d in 
clang::Parser::ParseUsingDirectiveOrDeclaration(clang::DeclaratorContext, 
clang::Parser::ParsedTemplateInfo const&, clang::SourceLocation&, 
clang::ParsedAttributes&) clang/lib/Parse/ParseDeclCXX.cpp:512:10
  #21 0x56363b46c161 in 
clang::Parser::ParseDeclaration(clang::DeclaratorContext, 
clang::SourceLocation&, clang::ParsedAttributes&, clang::ParsedAttributes&, 
clang::SourceLocation*) clang/lib/Parse/ParseDecl.cpp:1797:12
  #22 0x56363b55fb99 in 
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*, 
clang::ParsedAttributes&, clang::ParsedAttributes&) 
clang/lib/Parse/ParseStmt.cpp:247:16
  #23 0x56363b55cfb6 in 
clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector&, clang::Parser::ParsedStmtContext, clang::SourceLocation*) 
clang/lib/Parse/ParseStmt.cpp:115:20
  #24 0x56363b56c048 in clang::Parser::ParseCompoundS

[Lldb-commits] [PATCH] D131437: Don't index the skeleton CU when we have a fission compile unit.

2022-08-25 Thread Greg Clayton via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rG613336da8ce1: Don't index the skeleton CU when we have 
a fission compile unit. (authored by clayborg).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131437/new/

https://reviews.llvm.org/D131437

Files:
  lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.h
  lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
  lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
  lldb/test/API/functionalities/dwo/TestZeroDwoId.py
  lldb/test/API/functionalities/dwo/main.dwo.yaml
  lldb/test/API/functionalities/dwo/main.o.yaml

Index: lldb/test/API/functionalities/dwo/main.o.yaml
===
--- /dev/null
+++ lldb/test/API/functionalities/dwo/main.o.yaml
@@ -0,0 +1,212 @@
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_REL
+  Machine: EM_X86_64
+  SectionHeaderStringTable: .strtab
+Sections:
+  - Name:.text
+Type:SHT_PROGBITS
+Flags:   [ SHF_ALLOC, SHF_EXECINSTR ]
+AddressAlign:0x10
+Content: 554889E531C05DC30F1F8400554889E54883EC10C745FC897DF8488975F0E84883C4105DC3
+  - Name:.debug_abbrev
+Type:SHT_PROGBITS
+AddressAlign:0x1
+Content: 01110010171B0EB44219B0420EB1420711011206B3421700
+  - Name:.debug_info
+Type:SHT_PROGBITS
+AddressAlign:0x1
+Content: 2C00040008013100
+  - Name:.debug_addr
+Type:SHT_PROGBITS
+AddressAlign:0x1
+Content: ''
+  - Name:.debug_gnu_pubnames
+Type:SHT_PROGBITS
+AddressAlign:0x1
+Content: 210002003000190030666F6F002900306D61696E00
+  - Name:.debug_gnu_pubtypes
+Type:SHT_PROGBITS
+AddressAlign:0x1
+Content: 2100020030004F0090696E74006200906368617200
+  - Name:.comment
+Type:SHT_PROGBITS
+Flags:   [ SHF_MERGE, SHF_STRINGS ]
+AddressAlign:0x1
+EntSize: 0x1
+Content: 00636C616E672076657273696F6E2031362E302E30202868747470733A2F2F6769746875622E636F6D2F6C6C766D2F6C6C766D2D70726F6A65637420613836613537613033663831623362323561323839313737373235646662333733303164383836382900
+  - Name:.note.GNU-stack
+Type:SHT_PROGBITS
+AddressAlign:0x1
+  - Name:.eh_frame
+Type:SHT_X86_64_UNWIND
+Flags:   [ SHF_ALLOC ]
+AddressAlign:0x8
+Content: 1400017A5200017810011B0C070890011C001C0008410E108602430D06430C0708001C003C0021410E108602430D065C0C070800
+  - Name:.debug_line
+Type:SHT_PROGBITS
+AddressAlign:0x1
+Content: 47000400210101FB0E0D0001010101000101006D61696E2E63707009020105030A4B0500BD050A0A0859050306580206000101
+  - Name:.rela.text
+Type:SHT_RELA
+Flags:   [ SHF_INFO_LINK ]
+Link:.symtab
+AddressAlign:0x8
+Info:.text
+Relocations:
+  - Offset:  0x27
+Symbol:  _Z3foov
+Type:R_X86_64_PLT32
+Addend:  -4
+  - Name:.rela.debug_info
+Type:SHT_RELA
+Flags:   [ SHF_INFO_LINK ]
+Link:.symtab
+AddressAlign:0x8
+Info:.debug_info
+Relocations:
+  - Offset:  0x6
+Symbol:  .debug_abbrev
+Type:R_X86_64_32
+  - Offset:  0xC
+Symbol:  .debug_line
+Type:R_X86_64_32
+  - Offset:  0x10
+Symbol:  .debug_str
+Type:R_X86_64_32
+  - Offset:  0x14
+Symbol:  .debug_str
+Type:R_X86_64_32
+Addend:  58
+  - Offset:  0x20
+Symbol:  .text
+Type:R_X86_64_64
+  - Offset:  0x2C
+Symbol:  .debug_addr
+Type:R_X86_64_32
+  - Name:.rela.debug_addr
+Type:SHT_RELA
+

[Lldb-commits] [PATCH] D131437: Don't index the skeleton CU when we have a fission compile unit.

2022-08-24 Thread Pavel Labath via Phabricator via lldb-commits 
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

In D131437#3741132 , @clayborg wrote:

> So I can't get -fsplit-dwarf-inlining to emit anything when I try to cross 
> with clang. I add the flag but no extra function info gets emitted in the 
> dwarf in the main executable. I tried:
>
>   clang++ -gdwarf-5 -gsplit-dwarf -fsplit-dwarf-inlining -c main.cpp -o 
> main2.o 

You probably also need to enable optimizations for any inlining to happen 
(maybe not if you use always_inline). And you need to make the source 
sufficiently nontrivial so that there is some debug info to produce. For 
example, this code worked for me:

  $ cat main.cpp 
  int use(int);
  
  int inlined(int x) { return 1 + use(x); }
  
  int main() { return 2*inlined(57); }
  $ clang++ -gdwarf-5 -gsplit-dwarf -fsplit-dwarf-inlining -c main.cpp -O1



> I also tried to create an simple a.out program with a DWO_ID of zero. If it 
> obj2yaml and then to yaml2obj, something gets messed up in the binary, so not 
> sure if ojb2yaml + yaml2obj can handle fission binaries correctly.

I'm not surprised that fails, but possible the problem was not with fission. 
obj2yaml is not good at round-tripping fully linked binaries (with program 
headers and stuff). Things work much better for .o files (which should be 
sufficient for your needs here).

I also often find it easier to take the assembly output (`clang -s`) and tweak 
that, instead of going all the way to object code and then back to yaml.




Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h:339
   /// Value of DW_AT_GNU_dwo_id (v4) or dwo_id from CU header (v5).
-  uint64_t m_dwo_id;
+  llvm::Optional m_dwo_id;
 

clayborg wrote:
> labath wrote:
> > What's the relationship of this field and the m_is_dwo flag? Do we need 
> > both?
> I think the "m_is_dwo" is set to true if this is a DWO file, where m_dwo_id 
> is for the skeleton compile unit. So they are different and can't be derived 
> from each other if I understand the code correctly.
ok. makes sense.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131437/new/

https://reviews.llvm.org/D131437

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D131437: Don't index the skeleton CU when we have a fission compile unit.

2022-08-22 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg updated this revision to Diff 454695.
clayborg added a comment.

Added a test case that tests that we can load a .dwo file with a DWO ID of zero.
Was unable to get clang to emit extra stuff in the skeleton compile unit even 
with -fsplit-dwarf-inlining.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131437/new/

https://reviews.llvm.org/D131437

Files:
  lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.h
  lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
  lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
  lldb/test/API/functionalities/dwo/TestZeroDwoId.py
  lldb/test/API/functionalities/dwo/main.dwo.yaml
  lldb/test/API/functionalities/dwo/main.o.yaml

Index: lldb/test/API/functionalities/dwo/main.o.yaml
===
--- /dev/null
+++ lldb/test/API/functionalities/dwo/main.o.yaml
@@ -0,0 +1,212 @@
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_REL
+  Machine: EM_X86_64
+  SectionHeaderStringTable: .strtab
+Sections:
+  - Name:.text
+Type:SHT_PROGBITS
+Flags:   [ SHF_ALLOC, SHF_EXECINSTR ]
+AddressAlign:0x10
+Content: 554889E531C05DC30F1F8400554889E54883EC10C745FC897DF8488975F0E84883C4105DC3
+  - Name:.debug_abbrev
+Type:SHT_PROGBITS
+AddressAlign:0x1
+Content: 01110010171B0EB44219B0420EB1420711011206B3421700
+  - Name:.debug_info
+Type:SHT_PROGBITS
+AddressAlign:0x1
+Content: 2C00040008013100
+  - Name:.debug_addr
+Type:SHT_PROGBITS
+AddressAlign:0x1
+Content: ''
+  - Name:.debug_gnu_pubnames
+Type:SHT_PROGBITS
+AddressAlign:0x1
+Content: 210002003000190030666F6F002900306D61696E00
+  - Name:.debug_gnu_pubtypes
+Type:SHT_PROGBITS
+AddressAlign:0x1
+Content: 2100020030004F0090696E74006200906368617200
+  - Name:.comment
+Type:SHT_PROGBITS
+Flags:   [ SHF_MERGE, SHF_STRINGS ]
+AddressAlign:0x1
+EntSize: 0x1
+Content: 00636C616E672076657273696F6E2031362E302E30202868747470733A2F2F6769746875622E636F6D2F6C6C766D2F6C6C766D2D70726F6A65637420613836613537613033663831623362323561323839313737373235646662333733303164383836382900
+  - Name:.note.GNU-stack
+Type:SHT_PROGBITS
+AddressAlign:0x1
+  - Name:.eh_frame
+Type:SHT_X86_64_UNWIND
+Flags:   [ SHF_ALLOC ]
+AddressAlign:0x8
+Content: 1400017A5200017810011B0C070890011C001C0008410E108602430D06430C0708001C003C0021410E108602430D065C0C070800
+  - Name:.debug_line
+Type:SHT_PROGBITS
+AddressAlign:0x1
+Content: 47000400210101FB0E0D0001010101000101006D61696E2E63707009020105030A4B0500BD050A0A0859050306580206000101
+  - Name:.rela.text
+Type:SHT_RELA
+Flags:   [ SHF_INFO_LINK ]
+Link:.symtab
+AddressAlign:0x8
+Info:.text
+Relocations:
+  - Offset:  0x27
+Symbol:  _Z3foov
+Type:R_X86_64_PLT32
+Addend:  -4
+  - Name:.rela.debug_info
+Type:SHT_RELA
+Flags:   [ SHF_INFO_LINK ]
+Link:.symtab
+AddressAlign:0x8
+Info:.debug_info
+Relocations:
+  - Offset:  0x6
+Symbol:  .debug_abbrev
+Type:R_X86_64_32
+  - Offset:  0xC
+Symbol:  .debug_line
+Type:R_X86_64_32
+  - Offset:  0x10
+Symbol:  .debug_str
+Type:R_X86_64_32
+  - Offset:  0x14
+Symbol:  .debug_str
+Type:R_X86_64_32
+Addend:  58
+  - Offset:  0x20
+Symbol:  .text
+Type:R_X86_64_64
+  - Offset:  0x2C
+Symbol:  .debug_addr
+Type:R_X86_64_32
+  - N

[Lldb-commits] [PATCH] D131437: Don't index the skeleton CU when we have a fission compile unit.

2022-08-22 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg added a comment.

So I can't get -fsplit-dwarf-inlining to emit anything when I try to cross with 
clang. I add the flag but no extra function info gets emitted in the dwarf in 
the main executable. I tried:

  clang++ -gdwarf-5 -gsplit-dwarf -fsplit-dwarf-inlining -c main.cpp -o main2.o 

I also tried to create an simple a.out program with a DWO_ID of zero. If it 
obj2yaml and then to yaml2obj, something gets messed up in the binary, so not 
sure if ojb2yaml + yaml2obj can handle fission binaries correctly.

Any ideas?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131437/new/

https://reviews.llvm.org/D131437

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D131437: Don't index the skeleton CU when we have a fission compile unit.

2022-08-19 Thread Pavel Labath via Phabricator via lldb-commits 
labath added a comment.

In D131437#3710203 , @clayborg wrote:

> In D131437#3709921 , @labath wrote:
>
>> Seems reasonable, but could use a test case, though I'm not sure what would 
>> be the best way to approach that. I suppose one could dump the index of one 
>> of these dwo-less files, and then make sure it's contents are right (empty?).
>
> That is what I was struggling with. I might be able to use lldb-test to dump 
> a type lookup on a name that used to appear in both the DWO file and in the 
> skeleton compile unit and make sure no error string from the parsing gets 
> emitted? I haven't used lldb-test much, but is this possible to expect output 
> and make sure the error that detected this issue is not emitted once it is 
> fixed? The test would create a binary with -fsplit-dwarf-inlining enabled and 
> make sure that the skeleton compile unit ends up having a type from a type 
> template that _could_ be found if this fix wasn't there, then make sure when 
> we do a type lookup we don't see the error message. Let me know if you have 
> any other ideas on how to do this.

Yeah, that's pretty much what I had in mind. I think it should be sufficient to 
run `lldb-test symbols` on this binary. Among other things, that will dump the 
contents of the dwarf index, and we can verify that it is empty. A good way to 
that is to use CHECK/CHECK-NEXT/EMPTY to match the lines before after the place 
where the output should appear. So, something like this might work:

  # CHECK: Function basenames:
  ## if the next line is empty then no entries have been printed
  # CHECK-EMPTY:


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131437/new/

https://reviews.llvm.org/D131437

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D131437: Don't index the skeleton CU when we have a fission compile unit.

2022-08-09 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg added a comment.

In D131437#3709921 , @labath wrote:

> Seems reasonable, but could use a test case, though I'm not sure what would 
> be the best way to approach that. I suppose one could dump the index of one 
> of these dwo-less files, and then make sure it's contents are right (empty?).

That is what I was struggling with. I might be able to use lldb-test to dump a 
type lookup on a name that used to appear in both the DWO file and in the 
skeleton compile unit and make sure no error string from the parsing gets 
emitted? I haven't used lldb-test much, but is this possible to expect output 
and make sure the error that detected this issue is not emitted once it is 
fixed? The test would create a binary with -fsplit-dwarf-inlining enabled and 
make sure that the skeleton compile unit ends up having a type from a type 
template that _could_ be found if this fix wasn't there, then make sure when we 
do a type lookup we don't see the error message. Let me know if you have any 
other ideas on how to do this.

> The m_dwo_id change also looks like its fixing a bug where we could end up 
> mistakenly associating a regular unit (from the main exe file) with a split 
> unit from a dwp file if that split unit happens to have a dwo id of zero. 
> That might be another test vector.

yeah, I guess we would test this by making a DWO ID of zero and making sure it 
works. Doesn't matter if it is in a .dwo file in a .dwp file right? Just a test 
with a "a.out" binary that contains a skeleton compile unit that has a DWO ID 
of zero and a corresponding .dwo file that has this same ID inside of it right?




Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h:339
   /// Value of DW_AT_GNU_dwo_id (v4) or dwo_id from CU header (v5).
-  uint64_t m_dwo_id;
+  llvm::Optional m_dwo_id;
 

labath wrote:
> What's the relationship of this field and the m_is_dwo flag? Do we need both?
I think the "m_is_dwo" is set to true if this is a DWO file, where m_dwo_id is 
for the skeleton compile unit. So they are different and can't be derived from 
each other if I understand the code correctly.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131437/new/

https://reviews.llvm.org/D131437

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D131437: Don't index the skeleton CU when we have a fission compile unit.

2022-08-09 Thread Pavel Labath via Phabricator via lldb-commits 
labath added a comment.

Seems reasonable, but could use a test case, though I'm not sure what would be 
the best way to approach that. I suppose one could dump the index of one of 
these dwo-less files, and then make sure it's contents are right (empty?).

The m_dwo_id change also looks like its fixing a bug where we could end up 
mistakenly associating a regular unit (from the main exe file) with a split 
unit from a dwp file if that split unit happens to have a dwo id of zero. That 
might be another test vector.




Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h:339
   /// Value of DW_AT_GNU_dwo_id (v4) or dwo_id from CU header (v5).
-  uint64_t m_dwo_id;
+  llvm::Optional m_dwo_id;
 

What's the relationship of this field and the m_is_dwo flag? Do we need both?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131437/new/

https://reviews.llvm.org/D131437

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D131437: Don't index the skeleton CU when we have a fission compile unit.

2022-08-08 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg created this revision.
clayborg added reviewers: labath, JDevlieghere.
Herald added a subscriber: arphaman.
Herald added a project: All.
clayborg requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

When fission is enabled, we were indexing the skeleton CU _and_ the .dwo CU. 
Issues arise when users enable compiler options that add extra data to the 
skeleton CU (like -fsplit-dwarf-inlining) and there can end up being types in 
the skeleton CU due to template parameters. We never want to index this 
information since the .dwo file has the real definition, and we really don't 
want function prototypes from this info since all parameters are removed. The 
index doesn't work correctly if it does index the skeleton CU as the DIE offset 
will assume it is from the .dwo file, so even if we do index the skeleton CU, 
the index entries will try and grab information from the .dwo file using the 
wrong DIE offset which can cause errors to be displayed or even worse, if the 
DIE offsets is valid in the .dwo CU, the wrong DIE will be used.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D131437

Files:
  lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
  lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
  lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp

Index: lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/ManualDWARFIndex.cpp
@@ -148,19 +148,36 @@
 
   const LanguageType cu_language = SymbolFileDWARF::GetLanguage(unit);
 
-  IndexUnitImpl(unit, cu_language, set);
-
-  if (SymbolFileDWARFDwo *dwo_symbol_file = unit.GetDwoSymbolFile()) {
-// Type units in a dwp file are indexed separately, so we just need to
-// process the split unit here. However, if the split unit is in a dwo file,
-// then we need to process type units here.
-if (dwo_symbol_file == dwp) {
-  IndexUnitImpl(unit.GetNonSkeletonUnit(), cu_language, set);
-} else {
-  DWARFDebugInfo &dwo_info = dwo_symbol_file->DebugInfo();
-  for (size_t i = 0; i < dwo_info.GetNumUnits(); ++i)
-IndexUnitImpl(*dwo_info.GetUnitAtIndex(i), cu_language, set);
+  // First check if the unit has a DWO ID. If it does then we only want to index
+  // the .dwo file or nothing at all. If we have a compile unit where we can't
+  // locate the .dwo/.dwp file we don't want to index anything from the skeleton
+  // compile unit because it is usally has no children unless
+  // -fsplit-dwarf-inlining was used at compile time. This option will add a
+  // copy of all DW_TAG_subprogram and any contained DW_TAG_inline_subroutine
+  // DIEs so that symbolication will still work in the absence of the .dwo/.dwp
+  // file, but the functions have no return types and all arguments and locals
+  // have been removed. So we don't want to index any of these hacked up
+  // function types. Types can still exist in the skeleton compile unit DWARF
+  // though as some functions have template parameter types and other things
+  // that cause extra copies of types to be included, but we should find these
+  // types in the .dwo file only as methods could have return types removed and
+  // we don't have to index incomplete types from the skeletone compile unit.
+  if (unit.GetDWOId()) {
+if (SymbolFileDWARFDwo *dwo_symbol_file = unit.GetDwoSymbolFile()) {
+  // Type units in a dwp file are indexed separately, so we just need to
+  // process the split unit here. However, if the split unit is in a dwo file,
+  // then we need to process type units here.
+  if (dwo_symbol_file == dwp) {
+IndexUnitImpl(unit.GetNonSkeletonUnit(), cu_language, set);
+  } else {
+DWARFDebugInfo &dwo_info = dwo_symbol_file->DebugInfo();
+for (size_t i = 0; i < dwo_info.GetNumUnits(); ++i)
+  IndexUnitImpl(*dwo_info.GetUnitAtIndex(i), cu_language, set);
+  }
 }
+  } else {
+// We either have a normal compile unit which we want to index.
+IndexUnitImpl(unit, cu_language, set);
   }
 }
 
Index: lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
===
--- lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
+++ lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h
@@ -51,7 +51,7 @@
   uint64_t m_type_hash = 0;
   uint32_t m_type_offset = 0;
 
-  uint64_t m_dwo_id = 0;
+  llvm::Optional m_dwo_id;
 
   DWARFUnitHeader() = default;
 
@@ -67,7 +67,7 @@
   }
   uint64_t GetTypeHash() const { return m_type_hash; }
   dw_offset_t GetTypeOffset() const { return m_type_offset; }
-  uint64_t GetDWOId() const { return m_dwo_id; }
+  llvm::Optional GetDWOId() const { return m_dwo_id; }
   bool IsTypeUnit() const {
 return m_unit_type == llvm::dwarf::DW_UT_type ||
m_unit_type == llvm::dwarf::DW_U