-
Couldn't load subscription status.
- Fork 15k
[lldb] Implement ProcessGDBRemote support for ReadMemoryRanges #164311
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
Changes from all commits
a7ba9a5
e5f3220
b3cbe2f
ca9f528
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -45,3 +45,30 @@ def test_NSError_p(self): | |
| ], | ||
| ) | ||
| self.runCmd("process continue") | ||
|
|
||
| @skipIfOutOfTreeDebugserver | ||
| def test_runtime_types_efficient_memreads(self): | ||
| # Test that we use an efficient reading of memory when reading | ||
| # Objective-C method descriptions. | ||
| logfile = os.path.join(self.getBuildDir(), "log.txt") | ||
| self.runCmd(f"log enable -f {logfile} gdb-remote packets process") | ||
| self.addTearDownHook(lambda: self.runCmd("log disable gdb-remote packets")) | ||
|
|
||
| self.build() | ||
| self.target, process, thread, bkpt = lldbutil.run_to_source_breakpoint( | ||
| self, "// Break here for NSString tests", lldb.SBFileSpec("main.m", False) | ||
| ) | ||
|
|
||
| self.runCmd(f"proc plugin packet send StartTesting", check=False) | ||
| self.expect('expression str = [NSString stringWithCString: "new"]') | ||
| self.runCmd(f"proc plugin packet send EndTesting", check=False) | ||
|
|
||
| self.assertTrue(os.path.exists(logfile)) | ||
| log_text = open(logfile).read() | ||
| log_text = log_text.split("StartTesting", 1)[-1].split("EndTesting", 1)[0] | ||
|
|
||
| # This test is only checking that the packet it used at all (and that | ||
| # no errors are produced). It doesn't check that the packet is being | ||
| # used to solve a problem in an optimal way. | ||
| self.assertIn("MultiMemRead:", log_text) | ||
| self.assertNotIn("MultiMemRead error", log_text) | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does that text appear if there's an error? Won't it just be an Exx reply code from debugserver? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ohh i should add a comment about this, the sneaky thing is that I also enabled the gdbremote process log |
||
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.
Also assert that it is in there one or N times whatever is correct.
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.
Sadly I don't think we can do this, as it is very dependent on debug info for core objective C libraries. I wish we had a more direct way of testing things, Jason and I could not come up with anything better
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.
If we had a command that exclusively could be completed with only a MultiMemRead, we might be able to assert that no x/m packets were sent. But this core operation will still do memory reads to get c-strings for the methods; we didn't tackle Process::MultiCStringRead, but even if we had there would be a handful of simple memory reads issued while evaluating the expression. I think confirming the presence of at least one MultiMemRead: packet may be the best we could do here.
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.
Understood. Then add a comment to that effect.
This makes it clear the test is not checking whether the underlying layers batch reads in some optimal way. Just that it uses the new thing at all.
I want to have a look around lldb for a non-Darwin use for this packet, might be a case where we can expect only one. I'm fine with these tests as they are though.