[Lldb-commits] [PATCH] D35740: Fix PR33875 by distinguishing between DWO and clang modules

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I looked at this briefly last week but I could not find a good fix in the 
amount of time I had left. This fixes the current test failure, but it does not 
fix the underlying bug, which is that we (sometimes?) set the compile unit 
offset for non-dwo, non-dsym DIEs as 0. This works fine if all compile units 
are regular dwarf as we have logic to locate the containing CU if the offset is 
zero. However, it can fail in case of mixed dwarf and dwo compile units. My 
guess is you could still reproduce this bug with a so file that has a dwo 
compile unit at offset zero.

That said, I don't think this makes things any worse, so I have no objections 
to this patch.


Repository:
  rL LLVM

https://reviews.llvm.org/D35740



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

Re: [Lldb-commits] [PATCH] D35740: Fix PR33875 by distinguishing between DWO and clang modules

[David Blaikie via lldb-commits]

On Sun, Jul 23, 2017 at 10:54 AM Adrian Prantl  wrote:

> On Jul 22, 2017, at 2:26 PM, David Blaikie  wrote:
>
>
>
> On Fri, Jul 21, 2017 at 6:14 PM Jim Ingham  wrote:
>
>> Not at present, but you presumably know more about this than I do.  Part
>> of the point of Greg's extracting the DWARF parser from lldb and making it
>> into it's own library in llvm was precisely so that somebody could then
>> write a simple wrapper tool that would poke it with not necessarily
>> complete but interesting canned bits of DWARF and see that it does the
>> right thing.  I thought you were involved with the reviews for that work?
>
>
> Yep yep - though not necessarily clear on the bigger picture goals in
> terms of which components were going where in the long term.
>
>
>>   I was not paying attention to the details of that effort as DWARF
>> parsing's not really my thing.
>>
>> Anyway, the extraction of the DWARF parser was Greg's last act before
>> leaving Apple, and the project stalled at that point.  I don't imagine he
>> could have gotten that code into llvm without some testing, so the kind of
>> test you are thinking of should be done using whatever mechanism you guys
>> devised for the new llvm dwarf parser.
>
>
> Adrian - any chance something like the DwarfGenerator stuff in LLVM could
> be used to test this code?
>
>
>> Of course, it's less interesting to test the llvm version of the DWARF
>> parser if lldb's not using it, so for that to be directly relevant here
>> that piece of work would need to be done.
>>
>
> Perhaps - or reusing the same testing approach without that. Though I
> think this particular failure/fix was in a higher/lower different layer
> than the pure parsing stuff in LLVM, but I could be wrong - there's
> sufficient divergence it's not obvious from a few class names, etc, to tell
> how much overlap (& where) there is.
>
>
> Yes, I would also say that this is one level above the pure parsing. This
> is how LLDB interprets the data. Once the LLVM DWARF parser (which is
> architected more for testability) is complete enough to be used inside
> LLDB, there is no reason to not also implement this level
> (cross-referencing dwarf+dwo) inside LLVM and properly test with a unit
> test or a yaml object description.
>

Any reason this would need to wait until it's sunk into LLVM? It seems like
this kind of testing would be useful to do in LLDB no matter how many
libraries are sunk into LLVM - how far off/much work will it be to have
this sort of testing available in LLDB?


> Inside LLDB an end-to-end test like the existing one is as good as it gets
> now.
>
> -- adrian
>
>
>
>>
>> Jim
>>
>>
>>
>> > On Jul 21, 2017, at 5:51 PM, David Blaikie  wrote:
>> >
>> >
>> >
>> > On Fri, Jul 21, 2017 at 4:05 PM Greg Clayton via Phabricator <
>> revi...@reviews.llvm.org> wrote:
>> > clayborg accepted this revision.
>> > clayborg added a comment.
>> >
>> > Looks like there already is a test case that was failing as Jim
>> mentioned. Accepting based on that.
>> >
>> > Ah, I was thinking more a test that would've failed when LLDB regressed
>> (regardless of whether Clang was still producing this DWARF or not) - does
>> LLDB have tests like that? (either binary, asm, or some other terse way of
>> writing DWARF directly to test "does LLDB do the right thing with this
>> DWARF" sort of tests?)
>> >
>> >
>> >
>> > https://reviews.llvm.org/D35740
>> >
>> >
>> >
>>
>>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D35740: Fix PR33875 by distinguishing between DWO and clang modules

[Phabricator via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL308850: Fix PR33875 by distinguishing between DWO and clang 
modules (authored by adrian).

Changed prior to commit:
  https://reviews.llvm.org/D35740?vs=107734&id=107836#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D35740

Files:
  
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
  lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp


Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
@@ -61,6 +61,12 @@
 }
 
 DWARFCompileUnit *SymbolFileDWARFDwo::GetCompileUnit() {
+  // A clang module is found via a skeleton CU, but is not a proper DWO.
+  // Clang modules have a .debug_info section instead of the *_dwo variant.
+  if (auto *section_list = m_obj_file->GetSectionList(false))
+if (section_list->FindSectionByType(eSectionTypeDWARFDebugInfo, true))
+  return nullptr;
+
   // Only dwo files with 1 compile unit is supported
   if (GetNumCompileUnits() == 1)
 return DebugInfo()->GetCompileUnitAtIndex(0);
Index: 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
===
--- 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
+++ 
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
@@ -9,8 +9,6 @@
 
 mydir = TestBase.compute_mydir(__file__)
 
-@expectedFailureAll(bugnumber="llvm.org/pr33875", oslist=["linux"],
-compiler="clang", compiler_version=[">", "6.0"])
 @add_test_categories(["gmodules"])
 def test_specialized_typedef_from_pch(self):
 self.build()


Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
@@ -61,6 +61,12 @@
 }
 
 DWARFCompileUnit *SymbolFileDWARFDwo::GetCompileUnit() {
+  // A clang module is found via a skeleton CU, but is not a proper DWO.
+  // Clang modules have a .debug_info section instead of the *_dwo variant.
+  if (auto *section_list = m_obj_file->GetSectionList(false))
+if (section_list->FindSectionByType(eSectionTypeDWARFDebugInfo, true))
+  return nullptr;
+
   // Only dwo files with 1 compile unit is supported
   if (GetNumCompileUnits() == 1)
 return DebugInfo()->GetCompileUnitAtIndex(0);
Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
@@ -9,8 +9,6 @@
 
 mydir = TestBase.compute_mydir(__file__)
 
-@expectedFailureAll(bugnumber="llvm.org/pr33875", oslist=["linux"],
-compiler="clang", compiler_version=[">", "6.0"])
 @add_test_categories(["gmodules"])
 def test_specialized_typedef_from_pch(self):
 self.build()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D35740: Fix PR33875 by distinguishing between DWO and clang modules

[Adrian Prantl via lldb-commits]

> On Jul 22, 2017, at 2:26 PM, David Blaikie  wrote:
> 
> 
> 
> On Fri, Jul 21, 2017 at 6:14 PM Jim Ingham  > wrote:
> Not at present, but you presumably know more about this than I do.  Part of 
> the point of Greg's extracting the DWARF parser from lldb and making it into 
> it's own library in llvm was precisely so that somebody could then write a 
> simple wrapper tool that would poke it with not necessarily complete but 
> interesting canned bits of DWARF and see that it does the right thing.  I 
> thought you were involved with the reviews for that work?
> 
> Yep yep - though not necessarily clear on the bigger picture goals in terms 
> of which components were going where in the long term.
>  
>   I was not paying attention to the details of that effort as DWARF parsing's 
> not really my thing.
> 
> Anyway, the extraction of the DWARF parser was Greg's last act before leaving 
> Apple, and the project stalled at that point.  I don't imagine he could have 
> gotten that code into llvm without some testing, so the kind of test you are 
> thinking of should be done using whatever mechanism you guys devised for the 
> new llvm dwarf parser. 
> 
> Adrian - any chance something like the DwarfGenerator stuff in LLVM could be 
> used to test this code?
>  
> Of course, it's less interesting to test the llvm version of the DWARF parser 
> if lldb's not using it, so for that to be directly relevant here that piece 
> of work would need to be done.
> 
> Perhaps - or reusing the same testing approach without that. Though I think 
> this particular failure/fix was in a higher/lower different layer than the 
> pure parsing stuff in LLVM, but I could be wrong - there's sufficient 
> divergence it's not obvious from a few class names, etc, to tell how much 
> overlap (& where) there is.

Yes, I would also say that this is one level above the pure parsing. This is 
how LLDB interprets the data. Once the LLVM DWARF parser (which is architected 
more for testability) is complete enough to be used inside LLDB, there is no 
reason to not also implement this level (cross-referencing dwarf+dwo) inside 
LLVM and properly test with a unit test or a yaml object description. Inside 
LLDB an end-to-end test like the existing one is as good as it gets now.

-- adrian
>  
> 
> Jim
> 
> 
> 
> > On Jul 21, 2017, at 5:51 PM, David Blaikie  > > wrote:
> >
> >
> >
> > On Fri, Jul 21, 2017 at 4:05 PM Greg Clayton via Phabricator 
> > mailto:revi...@reviews.llvm.org>> wrote:
> > clayborg accepted this revision.
> > clayborg added a comment.
> >
> > Looks like there already is a test case that was failing as Jim mentioned. 
> > Accepting based on that.
> >
> > Ah, I was thinking more a test that would've failed when LLDB regressed 
> > (regardless of whether Clang was still producing this DWARF or not) - does 
> > LLDB have tests like that? (either binary, asm, or some other terse way of 
> > writing DWARF directly to test "does LLDB do the right thing with this 
> > DWARF" sort of tests?)
> >
> >
> >
> > https://reviews.llvm.org/D35740 
> >
> >
> >
> 

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

Re: [Lldb-commits] [PATCH] D35740: Fix PR33875 by distinguishing between DWO and clang modules

[David Blaikie via lldb-commits]

On Fri, Jul 21, 2017 at 6:14 PM Jim Ingham  wrote:

> Not at present, but you presumably know more about this than I do.  Part
> of the point of Greg's extracting the DWARF parser from lldb and making it
> into it's own library in llvm was precisely so that somebody could then
> write a simple wrapper tool that would poke it with not necessarily
> complete but interesting canned bits of DWARF and see that it does the
> right thing.  I thought you were involved with the reviews for that work?


Yep yep - though not necessarily clear on the bigger picture goals in terms
of which components were going where in the long term.


>   I was not paying attention to the details of that effort as DWARF
> parsing's not really my thing.
>
> Anyway, the extraction of the DWARF parser was Greg's last act before
> leaving Apple, and the project stalled at that point.  I don't imagine he
> could have gotten that code into llvm without some testing, so the kind of
> test you are thinking of should be done using whatever mechanism you guys
> devised for the new llvm dwarf parser.


Adrian - any chance something like the DwarfGenerator stuff in LLVM could
be used to test this code?


> Of course, it's less interesting to test the llvm version of the DWARF
> parser if lldb's not using it, so for that to be directly relevant here
> that piece of work would need to be done.
>

Perhaps - or reusing the same testing approach without that. Though I think
this particular failure/fix was in a higher/lower different layer than the
pure parsing stuff in LLVM, but I could be wrong - there's sufficient
divergence it's not obvious from a few class names, etc, to tell how much
overlap (& where) there is.


>
> Jim
>
>
>
> > On Jul 21, 2017, at 5:51 PM, David Blaikie  wrote:
> >
> >
> >
> > On Fri, Jul 21, 2017 at 4:05 PM Greg Clayton via Phabricator <
> revi...@reviews.llvm.org> wrote:
> > clayborg accepted this revision.
> > clayborg added a comment.
> >
> > Looks like there already is a test case that was failing as Jim
> mentioned. Accepting based on that.
> >
> > Ah, I was thinking more a test that would've failed when LLDB regressed
> (regardless of whether Clang was still producing this DWARF or not) - does
> LLDB have tests like that? (either binary, asm, or some other terse way of
> writing DWARF directly to test "does LLDB do the right thing with this
> DWARF" sort of tests?)
> >
> >
> >
> > https://reviews.llvm.org/D35740
> >
> >
> >
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D35740: Fix PR33875 by distinguishing between DWO and clang modules

[Jim Ingham via lldb-commits]

Not at present, but you presumably know more about this than I do.  Part of the 
point of Greg's extracting the DWARF parser from lldb and making it into it's 
own library in llvm was precisely so that somebody could then write a simple 
wrapper tool that would poke it with not necessarily complete but interesting 
canned bits of DWARF and see that it does the right thing.  I thought you were 
involved with the reviews for that work?  I was not paying attention to the 
details of that effort as DWARF parsing's not really my thing.

Anyway, the extraction of the DWARF parser was Greg's last act before leaving 
Apple, and the project stalled at that point.  I don't imagine he could have 
gotten that code into llvm without some testing, so the kind of test you are 
thinking of should be done using whatever mechanism you guys devised for the 
new llvm dwarf parser.  Of course, it's less interesting to test the llvm 
version of the DWARF parser if lldb's not using it, so for that to be directly 
relevant here that piece of work would need to be done.

Jim



> On Jul 21, 2017, at 5:51 PM, David Blaikie  wrote:
> 
> 
> 
> On Fri, Jul 21, 2017 at 4:05 PM Greg Clayton via Phabricator 
>  wrote:
> clayborg accepted this revision.
> clayborg added a comment.
> 
> Looks like there already is a test case that was failing as Jim mentioned. 
> Accepting based on that.
> 
> Ah, I was thinking more a test that would've failed when LLDB regressed 
> (regardless of whether Clang was still producing this DWARF or not) - does 
> LLDB have tests like that? (either binary, asm, or some other terse way of 
> writing DWARF directly to test "does LLDB do the right thing with this DWARF" 
> sort of tests?)
>  
> 
> 
> https://reviews.llvm.org/D35740
> 
> 
> 

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

Re: [Lldb-commits] [PATCH] D35740: Fix PR33875 by distinguishing between DWO and clang modules

[David Blaikie via lldb-commits]

On Fri, Jul 21, 2017 at 4:05 PM Greg Clayton via Phabricator <
revi...@reviews.llvm.org> wrote:

> clayborg accepted this revision.
> clayborg added a comment.
>
> Looks like there already is a test case that was failing as Jim mentioned.
> Accepting based on that.
>

Ah, I was thinking more a test that would've failed when LLDB regressed
(regardless of whether Clang was still producing this DWARF or not) - does
LLDB have tests like that? (either binary, asm, or some other terse way of
writing DWARF directly to test "does LLDB do the right thing with this
DWARF" sort of tests?)


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

[Lldb-commits] [PATCH] D35740: Fix PR33875 by distinguishing between DWO and clang modules

[Greg Clayton via Phabricator via lldb-commits]

clayborg accepted this revision.
clayborg added a comment.

Looks like there already is a test case that was failing as Jim mentioned. 
Accepting based on that.


https://reviews.llvm.org/D35740



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

[Lldb-commits] [PATCH] D35740: Fix PR33875 by distinguishing between DWO and clang modules

[Jim Ingham via Phabricator via lldb-commits]

jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.

I was under the impression that this was found by a test case failure.

Anyway, given that we've got different kinds of DWARF CU's, wouldn't it be 
better to add an attribute describing them, rather than using semi-unrelated 
pieces of information like this?  I wouldn't hold up this patch on that 
suggestion, but this does seem kind of indirect...


https://reviews.llvm.org/D35740



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

[Lldb-commits] [PATCH] D35740: Fix PR33875 by distinguishing between DWO and clang modules

[Adrian Prantl via Phabricator via lldb-commits]

aprantl updated this revision to Diff 107734.
aprantl added a comment.

No with testcase of sorts.


https://reviews.llvm.org/D35740

Files:
  packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp


Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
@@ -61,6 +61,12 @@
 }
 
 DWARFCompileUnit *SymbolFileDWARFDwo::GetCompileUnit() {
+  // A clang module is found via a skeleton CU, but is not a proper DWO.
+  // Clang modules have a .debug_info section instead of the *_dwo variant.
+  if (auto *section_list = m_obj_file->GetSectionList(false))
+if (section_list->FindSectionByType(eSectionTypeDWARFDebugInfo, true))
+  return nullptr;
+
   // Only dwo files with 1 compile unit is supported
   if (GetNumCompileUnits() == 1)
 return DebugInfo()->GetCompileUnitAtIndex(0);
Index: 
packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
===
--- packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
+++ packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
@@ -9,8 +9,6 @@
 
 mydir = TestBase.compute_mydir(__file__)
 
-@expectedFailureAll(bugnumber="llvm.org/pr33875", oslist=["linux"],
-compiler="clang", compiler_version=[">", "6.0"])
 @add_test_categories(["gmodules"])
 def test_specialized_typedef_from_pch(self):
 self.build()


Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
@@ -61,6 +61,12 @@
 }
 
 DWARFCompileUnit *SymbolFileDWARFDwo::GetCompileUnit() {
+  // A clang module is found via a skeleton CU, but is not a proper DWO.
+  // Clang modules have a .debug_info section instead of the *_dwo variant.
+  if (auto *section_list = m_obj_file->GetSectionList(false))
+if (section_list->FindSectionByType(eSectionTypeDWARFDebugInfo, true))
+  return nullptr;
+
   // Only dwo files with 1 compile unit is supported
   if (GetNumCompileUnits() == 1)
 return DebugInfo()->GetCompileUnitAtIndex(0);
Index: packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
===
--- packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
+++ packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
@@ -9,8 +9,6 @@
 
 mydir = TestBase.compute_mydir(__file__)
 
-@expectedFailureAll(bugnumber="llvm.org/pr33875", oslist=["linux"],
-compiler="clang", compiler_version=[">", "6.0"])
 @add_test_categories(["gmodules"])
 def test_specialized_typedef_from_pch(self):
 self.build()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D35740: Fix PR33875 by distinguishing between DWO and clang modules

[David Blaikie via Phabricator via lldb-commits]

dblaikie added a comment.

(Presumably this could use a test case?)


Repository:
  rL LLVM

https://reviews.llvm.org/D35740



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

[Lldb-commits] [PATCH] D35740: Fix PR33875 by distinguishing between DWO and clang modules

[Adrian Prantl via Phabricator via lldb-commits]

aprantl created this revision.

The DWO handling code can get confused by clang modules which also use skeleton 
CUs to point to the object file with the full debug info. This patch detects 
whether an object is a "real" DWO or a clang module and prevents LLDB from 
interpreting clang modules as DWO. This fixes the regression in 
TestWithModuleDebugging.

http://llvm.org/bugs/show_bug.cgi?id=33875


Repository:
  rL LLVM

https://reviews.llvm.org/D35740

Files:
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp


Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
@@ -61,6 +61,12 @@
 }
 
 DWARFCompileUnit *SymbolFileDWARFDwo::GetCompileUnit() {
+  // A clang module is found via a skeleton CU, but is not a proper DWO.
+  // Clang modules have a .debug_info section instead of the *_dwo variant.
+  if (auto *section_list = m_obj_file->GetSectionList(false))
+if (section_list->FindSectionByType(eSectionTypeDWARFDebugInfo, true))
+  return nullptr;
+
   // Only dwo files with 1 compile unit is supported
   if (GetNumCompileUnits() == 1)
 return DebugInfo()->GetCompileUnitAtIndex(0);


Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
@@ -61,6 +61,12 @@
 }
 
 DWARFCompileUnit *SymbolFileDWARFDwo::GetCompileUnit() {
+  // A clang module is found via a skeleton CU, but is not a proper DWO.
+  // Clang modules have a .debug_info section instead of the *_dwo variant.
+  if (auto *section_list = m_obj_file->GetSectionList(false))
+if (section_list->FindSectionByType(eSectionTypeDWARFDebugInfo, true))
+  return nullptr;
+
   // Only dwo files with 1 compile unit is supported
   if (GetNumCompileUnits() == 1)
 return DebugInfo()->GetCompileUnitAtIndex(0);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits