[LLDB] Skip TestMultipleSlides.py on Windows #165604
Conversation
|
@llvm/pr-subscribers-lldb Author: nerix (Nerixyz) ChangesAfter the default PDB plugin changed to the native one (#165363), this test failed, because it uses the size of public symbols and the native plugin sets the size to 0 (as PDB doesn't include this information explicitly). DWARF emitted by clang on Windows doesn't include the public symbols, so LLDB fell back to PDB. Full diff: https://github.com/llvm/llvm-project/pull/165604.diff 1 Files Affected:
diff --git a/lldb/test/API/functionalities/multiple-slides/TestMultipleSlides.py b/lldb/test/API/functionalities/multiple-slides/TestMultipleSlides.py
index 3d6b27fe68a1b..48db92b611cfa 100644
--- a/lldb/test/API/functionalities/multiple-slides/TestMultipleSlides.py
+++ b/lldb/test/API/functionalities/multiple-slides/TestMultipleSlides.py
@@ -12,6 +12,9 @@
class MultipleSlidesTestCase(TestBase):
NO_DEBUG_INFO_TESTCASE = True
+ # DWARF doesn't include public symbols on Windows, so LLDB falls back to the PDB.
+ # Symbols don't have a size in the native PDB plugin.
+ @skipIfWindows
def test_mulitple_slides(self):
"""Test that a binary can be slid multiple times correctly."""
self.build()
|
So if we had used lld when running this test on Windows with DWARF, it would've passed? |
This isn't compiled with DWARF, but linked with -gdwarf, so LLD generates a PDB.
Sorry, I was wrong. The intermediate object, I don't know how this works on other platforms if |
|
There is still some bug with DWARF not including some public symbols on Windows (e.g. vtable symbols). I found this a while ago, but haven't investigated more. |
|
In the interim, to unblock CI i suggest we either xfail the test or explicitly enable the DIA plugin on windows for this test |
| NO_DEBUG_INFO_TESTCASE = True | ||
|
|
||
| # The intermediate object main.o is compiled without debug info, but | ||
| # a.out is linked with `-gdwarf` on Windows. This creates a PDB. |
There was a problem hiding this comment.
Why does -gdwarf make LLD create a PDB? Seems counterintuitive. Is that just some odd side effect?
There was a problem hiding this comment.
I think it's because of this:
llvm-project/clang/lib/Driver/ToolChains/MSVC.cpp
Lines 167 to 168 in 7b98280
There was a problem hiding this comment.
Seems plausible. So clang-cl transforms -gdwarf into /Z7? Worth filing an issue to clarify what's going on
There was a problem hiding this comment.
Is Z7 the thing that instructs pdb? Vague memory that some other flag is needed
After the default PDB plugin changed to the native one (llvm#165363), this test failed, because it uses the size of public symbols and the native plugin sets the size to 0 (as PDB doesn't include this information explicitly). A PDB was built because the final executable in that test was linked with `-gdwarf`.
In #165604, a test was skipped on Windows, because the native PDB plugin didn't set sizes on symbols. While the test isn't compiled with debug info, it's linked with `-gdwarf`, causing a PDB to be created on Windows. This PDB will only contain the public symbols (written by the linker) and section information. The symbols themselves don't have a size, however the DIA SDK sets a size for them. It seems like, for these data symbols, the size given from DIA is the distance to the next symbol (or the section end). This PR implements the naive approach for the native plugin. The main difference is in function/code symbols. There, DIA searches for a corresponding `S_GPROC32` which have a "code size" that is sometimes slightly smaller than the difference to the next symbol.
3 participants
After the default PDB plugin changed to the native one (#165363), this test failed, because it uses the size of public symbols and the native plugin sets the size to 0 (as PDB doesn't include this information explicitly). A PDB was built because the final executable in that test was linked with
-gdwarf.