-
Notifications
You must be signed in to change notification settings - Fork 15.1k
[LLDB] Run API tests with PDB too #149305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
Nerixyz
wants to merge
2
commits into
llvm:main
Choose a base branch
from
Nerixyz:feat/pdb-tests
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
CXX_SOURCES := main.cpp | ||
|
||
include Makefile.rules |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
""" | ||
Test PDB enabled tests | ||
""" | ||
|
||
from lldbsuite.test.decorators import * | ||
from lldbsuite.test.lldbtest import * | ||
|
||
|
||
class TestBuildMethod(TestBase): | ||
TEST_WITH_PDB_DEBUG_INFO = True | ||
|
||
def test(self): | ||
self.build() | ||
self.assertTrue(self.dbg.CreateTarget(self.getBuildArtifact())) | ||
if self.getDebugInfo() == "native-pdb": | ||
self.expect( | ||
"target modules dump symfile", substrs=["SymbolFile native-pdb"] | ||
) | ||
if self.getDebugInfo() == "dia-pdb": | ||
self.expect("target modules dump symfile", substrs=["SymbolFile pdb"]) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
int main() { return 0; } |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not fold this into
setUpCommands
? Then we don't need to loop over these separatelyThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
setUpCommands
is a@classmethod
, so it gets the calling class type as it's argument, not the instance. I don't know if/why@classmethod
is needed there.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know that for sure, but I can imagine it being added just because the function didn't need the instance argument at the time. It may be possible to remove it.
That said, I'm not entirely happy with how these new categories are are behaving quite differently from the other debug info categories. The other categories change the kind of debug info that's being emitted -- not which code is parsing that debug info.
Having a
pdb
category to get clang to produce pdb debug info makes perfect sense. I'm not so sure about using that category to select the plugin kind -- particularly if the end goal is to remove the non-native plugin completely.When I made the suggestion to use settings I was imagining you would be setting it on a per-run basis via the
--setting
flag to dotest.py. Would that be an option?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's possible, but then we wouldn't be able to run the tests with both plugins in CI using
check-lldb
, right?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's correct. Is that your goal? (I haven't been following the overall discussion too closely).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, whatever way this is done, a
check-lldb-supersecretpdbthing
is better because then I only have to add that to llvm-zorg once. Any future changes to what gets run can be done in llvm-project and take effect right away.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this world, the command to run all pdb tests with the non-default plugin would be something like
llvm-lit --dotest-args="--category pdb --setting plugin.symbol-file.pdb.reader=foo"
. Besides needing to update zorg, another disadvantage of this approach is that there isn't a particularly clean way to skip/xfail a test for a particular pdb plugin, as the --setting thingy sort of works behind the back of the decorators.I've been thinking about this, and I think I've come to a conclusion that the thing that upsets me is not so much the existence of the category, as it's the existence of the plugin that it is testing. Ignoring the implementation differences, the difference in test coverage between native-pdb and dia-pdb is much bigger than "dwarf" and "dwo". It's kind of like "dwarf" and "dsym", but even bigger because the debug map eventually goes back to the dwarf implementation to parse the debug info. So, if those categories make sense (personally, I'm not convinced they all do), then these sort of do as well.
However, the very concept of trying to support both plugins bothers me. Windows is already the least supported lldb platform (counted by the number of passing tests for instance) and the one with the smallest number of active developers supporting it. Having those developers split their time trying to support both plugins sounds like a very bad idea to me. In fact, I would speculate that the reason that we still have two plugins is because there isn't a developer with sufficient time to actually merge the two.
So, if we're going to put our foot down for something, I think this should be the reason -- basically, say "we don't support more pdb things until pdb gets its act together". Unfortunately, I'm not in a position to be putting my foot down right now. However, if someone else (wink, wink) wants to put his foot down, I will support that foot however I can.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How unusable is the Native PDB plugin to debug with? Can we just make it the default now? I know there's some tests that pass with DIA PDB that don't with the native one, but are those actually blockers?
@Nerixyz @charles-zablit any big gaps that you're aware of?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll start a discourse thread for this. Linaro has reason to invest in Windows.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://discourse.llvm.org/t/rfc-removing-the-dia-pdb-plugin-from-lldb/87827
Once there's clarity there we can make a clear decision here too.