[Lldb-commits] [PATCH] D46588: [LLDB][lldb-mi] Add possibility to set breakpoints without selecting a target.
aprantl added a comment.
> The advantage of the second one is that we will have the ability to inject
> commands which depend on the results of previous commands (something that I
> think we will need, sooner or later).
That is worth considering. To write good tests that depend on previous results,
we probably want to have SBAPI-like Python scripting for lldb-mi available. To
make that work we would need to introduce an lldbmi.HandleCommand("-mycmd...")
interface that runs one command, blocks on it, and returns the output in a
string. And then we would need to export that to Python. Since the interface is
string-in-string-out, we could probably do it via C without even involving
SWIG. As an escape hatch to access features outside of the mi command set, we
could implement the -interpreter-exec mi command that passes its input to
SBAPI's HandleCommand() if need be.
Alternatively we could use gtest to write unittest-style lldb-mi tests directly
in C++, if going via Python is too messy. Again, we would do that in a blocking
or synchronized I/O mode.
Repository:
rL LLVM
https://reviews.llvm.org/D46588
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D46783: FileSpec objects that resolve to "." should have "." in m_filename and m_directory empty.
clayborg reclaimed this revision. clayborg added a comment. Reviving this patch so I can get the changes into LLDB. Clang is expecting an empty path in many locations and I don't feel comfortable changing remove_dots in clang after trying it. So I would like to use this patch to fix things in LLDB. https://reviews.llvm.org/D46783 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r332556 - Revert 332511 after reverting llvm revision 332508.
Author: gclayton
Date: Wed May 16 16:32:45 2018
New Revision: 332556
URL: http://llvm.org/viewvc/llvm-project?rev=332556=rev
Log:
Revert 332511 after reverting llvm revision 332508.
Modified:
lldb/trunk/unittests/Utility/FileSpecTest.cpp
Modified: lldb/trunk/unittests/Utility/FileSpecTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Utility/FileSpecTest.cpp?rev=332556=332555=332556=diff
==
--- lldb/trunk/unittests/Utility/FileSpecTest.cpp (original)
+++ lldb/trunk/unittests/Utility/FileSpecTest.cpp Wed May 16 16:32:45 2018
@@ -199,9 +199,9 @@ TEST(FileSpecTest, GetNormalizedPath) {
{"/..", "/"},
{"/.", "/"},
{"..", ".."},
- {".", "."},
+ {".", ""},
{"../..", "../.."},
- {"foo/..", "."},
+ {"foo/..", ""},
{"foo/../bar", "bar"},
{"../foo/..", ".."},
{"./foo", "foo"},
@@ -230,11 +230,11 @@ TEST(FileSpecTest, GetNormalizedPath) {
{R"(\..)", R"(\..)"},
// {R"(c:..)", R"(c:..)"},
{R"(..)", R"(..)"},
- {R"(.)", R"(.)"},
+ {R"(.)", R"()"},
// TODO: fix llvm::sys::path::remove_dots() to return "c:\" below.
{R"(c:..\..)", R"(c:\..\..)"},
{R"(..\..)", R"(..\..)"},
- {R"(foo\..)", R"(.)"},
+ {R"(foo\..)", R"()"},
{R"(foo\..\bar)", R"(bar)"},
{R"(..\foo\..)", R"(..)"},
{R"(.\foo)", R"(foo)"},
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D46934: Make ObjectFileMachO work on non-darwin platforms
aprantl added a comment. Does that mean we can now also remove the #ifdef __APPLE__ from the objectfile unit tests? https://reviews.llvm.org/D46934 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D46934: Make ObjectFileMachO work on non-darwin platforms
jasonmolenda accepted this revision. jasonmolenda added a comment. Thanks for untangling this Pavel, I hadn't noticed we weren't building this plugin for non-darwin systems. I'd agree with Adrian's comment that we should have a constants like LLDB_KERNEL_SUCCESS / LLDB_KERNEL_INVALID_ARGUMENT, I think the place where -1 was being returned currently would be considered incorrect (it's probably my fault for all I know ;) https://reviews.llvm.org/D46934 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D46783: FileSpec objects that resolve to "." should have "." in m_filename and m_directory empty.
clayborg abandoned this revision. clayborg added a comment. Fixed LLDB test botes with: Sendingunittests/Utility/FileSpecTest.cpp Transmitting file data .done Committing transaction... Committed revision 332511. https://reviews.llvm.org/D46783 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r332511 - Fix FileSpecTest after LLVM changes to remove_dots (https://reviews.llvm.org/D46887)
Author: gclayton
Date: Wed May 16 11:37:00 2018
New Revision: 332511
URL: http://llvm.org/viewvc/llvm-project?rev=332511=rev
Log:
Fix FileSpecTest after LLVM changes to remove_dots
(https://reviews.llvm.org/D46887)
Modified:
lldb/trunk/unittests/Utility/FileSpecTest.cpp
Modified: lldb/trunk/unittests/Utility/FileSpecTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Utility/FileSpecTest.cpp?rev=332511=332510=332511=diff
==
--- lldb/trunk/unittests/Utility/FileSpecTest.cpp (original)
+++ lldb/trunk/unittests/Utility/FileSpecTest.cpp Wed May 16 11:37:00 2018
@@ -199,9 +199,9 @@ TEST(FileSpecTest, GetNormalizedPath) {
{"/..", "/"},
{"/.", "/"},
{"..", ".."},
- {".", ""},
+ {".", "."},
{"../..", "../.."},
- {"foo/..", ""},
+ {"foo/..", "."},
{"foo/../bar", "bar"},
{"../foo/..", ".."},
{"./foo", "foo"},
@@ -230,11 +230,11 @@ TEST(FileSpecTest, GetNormalizedPath) {
{R"(\..)", R"(\..)"},
// {R"(c:..)", R"(c:..)"},
{R"(..)", R"(..)"},
- {R"(.)", R"()"},
+ {R"(.)", R"(.)"},
// TODO: fix llvm::sys::path::remove_dots() to return "c:\" below.
{R"(c:..\..)", R"(c:\..\..)"},
{R"(..\..)", R"(..\..)"},
- {R"(foo\..)", R"()"},
+ {R"(foo\..)", R"(.)"},
{R"(foo\..\bar)", R"(bar)"},
{R"(..\foo\..)", R"(..)"},
{R"(.\foo)", R"(foo)"},
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D46588: [LLDB][lldb-mi] Add possibility to set breakpoints without selecting a target.
polyakov.alex updated this revision to Diff 147117.
polyakov.alex added a comment.
I have all the patches I was sending. I will follow this topic until you decide
what to do with lldb-mi testing.
Repository:
rL LLVM
https://reviews.llvm.org/D46588
Files:
packages/Python/lldbsuite/test/tools/lldb-mi/breakpoint/TestMiBreak.py
tools/lldb-mi/MICmdCmdBreak.cpp
tools/lldb-mi/MICmnLLDBDebugSessionInfo.cpp
Index: tools/lldb-mi/MICmnLLDBDebugSessionInfo.cpp
===
--- tools/lldb-mi/MICmnLLDBDebugSessionInfo.cpp
+++ tools/lldb-mi/MICmnLLDBDebugSessionInfo.cpp
@@ -871,7 +871,10 @@
// Throws: None.
//--
lldb::SBTarget CMICmnLLDBDebugSessionInfo::GetTarget() const {
- return GetDebugger().GetSelectedTarget();
+ auto target = GetDebugger().GetSelectedTarget();
+ if (target.IsValid())
+return target;
+ return GetDebugger().GetDummyTarget();
}
//++
Index: tools/lldb-mi/MICmdCmdBreak.cpp
===
--- tools/lldb-mi/MICmdCmdBreak.cpp
+++ tools/lldb-mi/MICmdCmdBreak.cpp
@@ -148,6 +148,11 @@
CMICMDBASE_GETOPTION(pArgRestrictBrkPtToThreadId, OptionShort,
m_constStrArgNamedRestrictBrkPtToThreadId);
+ // Ask LLDB for the target to check if we have valid or dummy one.
+ CMICmnLLDBDebugSessionInfo (
+ CMICmnLLDBDebugSessionInfo::Instance());
+ lldb::SBTarget sbTarget = rSessionInfo.GetTarget();
+
m_bBrkPtEnabled = !pArgDisableBrkPt->GetFound();
m_bBrkPtIsTemp = pArgTempBrkPt->GetFound();
m_bHaveArgOptionThreadGrp = pArgThreadGroup->GetFound();
@@ -157,7 +162,12 @@
nThreadGrp);
m_strArgOptionThreadGrp = CMIUtilString::Format("i%d", nThreadGrp);
}
- m_bBrkPtIsPending = pArgPendingBrkPt->GetFound();
+
+ if (sbTarget == rSessionInfo.GetDebugger().GetDummyTarget())
+m_bBrkPtIsPending = true;
+ else
+m_bBrkPtIsPending = pArgPendingBrkPt->GetFound();
+
if (pArgLocation->GetFound())
m_brkName = pArgLocation->GetValue();
else if (m_bBrkPtIsPending) {
@@ -225,9 +235,6 @@
// Ask LLDB to create a breakpoint
bool bOk = MIstatus::success;
- CMICmnLLDBDebugSessionInfo (
- CMICmnLLDBDebugSessionInfo::Instance());
- lldb::SBTarget sbTarget = rSessionInfo.GetTarget();
switch (eBrkPtType) {
case eBreakPoint_ByAddress:
m_brkPt = sbTarget.BreakpointCreateByAddress(nAddress);
Index: packages/Python/lldbsuite/test/tools/lldb-mi/breakpoint/TestMiBreak.py
===
--- packages/Python/lldbsuite/test/tools/lldb-mi/breakpoint/TestMiBreak.py
+++ packages/Python/lldbsuite/test/tools/lldb-mi/breakpoint/TestMiBreak.py
@@ -143,6 +143,32 @@
self.expect("\^running")
self.expect("\*stopped,reason=\"breakpoint-hit\"")
+@skipIfWindows # llvm.org/pr24452: Get lldb-mi tests working on Windows.
+@skipIfFreeBSD # llvm.org/pr22411: Failure presumably due to known thread
races.
+@skipIfRemote # We do not currently support remote debugging via the MI.
+def test_lldbmi_break_insert_without_target(self):
+"""Test that 'lldb-mi --interpreter' can set breakpoints without
+selecting a valid target."""
+
+self.spawnLldbMi(args=None)
+
+# This command have to insert breakpoint to the dummy target.
+self.runCmd("-break-insert main")
+# FIXME function name is unknown on Darwin, fullname should be ??,
line is -1
+self.expect(
+
"\^done,bkpt={number=\"1\",type=\"breakpoint\",disp=\"keep\",enabled=\"y\","
+
"addr=\"0x\",func=\"\?\?\",file=\"\?\?\",fullname=\"\?\?/\?\?\","
+
"line=\"0\",pending=\[\"main\"\],times=\"0\",original-location=\"main\"}"
+)
+
+# Add a valid target.
+self.runCmd("-file-exec-and-symbols %s" % self.myexe)
+self.expect("\^done")
+
+self.runCmd("-exec-run")
+self.expect("\^running")
+self.expect("\*stopped,reason=\"breakpoint-hit\"")
+
@skipIfWindows # llvm.org/pr24452: Get lldb-mi tests working on Windows
@skipIfFreeBSD # llvm.org/pr22411: Failure presumably due to known thread
races
@skipIfRemote # We do not currently support remote debugging via the MI.
Index: tools/lldb-mi/MICmnLLDBDebugSessionInfo.cpp
===
--- tools/lldb-mi/MICmnLLDBDebugSessionInfo.cpp
+++ tools/lldb-mi/MICmnLLDBDebugSessionInfo.cpp
@@ -871,7 +871,10 @@
// Throws: None.
//--
lldb::SBTarget CMICmnLLDBDebugSessionInfo::GetTarget() const {
- return GetDebugger().GetSelectedTarget();
+ auto target = GetDebugger().GetSelectedTarget();
+ if (target.IsValid())
+return target;
+ return GetDebugger().GetDummyTarget();
}
//++
Index: tools/lldb-mi/MICmdCmdBreak.cpp
===
--- tools/lldb-mi/MICmdCmdBreak.cpp
+++
[Lldb-commits] [PATCH] D46588: [LLDB][lldb-mi] Add possibility to set breakpoints without selecting a target.
labath added inline comments. Comment at: lit/tools/lldb-mi/breakpoint/break-insert.test:14 +# CHECK-AFTER: ^running +# CHECK-AFTER: *stopped,reason="breakpoint-hit" + aprantl wrote: > labath wrote: > > aprantl wrote: > > > polyakov.alex wrote: > > > > aprantl wrote: > > > > > CHECK-AFTER is not recognized by FileCheck: > > > > > > > > > > https://www.llvm.org/docs/CommandGuide/FileCheck.html > > > > > > > > > > You probably saw this in a testcase that ran FileCheck twice, one > > > > > time with the CHECK prefix and once with a custom > > > > > `--check-prefix=CHECK-AFTER` which is a common trick to have more > > > > > than one set of FileCheck directives in a single file. > > > > Yes. There is no problem to write test using only `CHECK` and > > > > `CHECK-NOT`, but as I said, in lldb-mi's output we can't find any info > > > > about hitting breakpoint, so the question is: is it enough to check > > > > that breakpoint was set to a selected target? > > > > in lldb-mi's output we can't find any info about hitting breakpoint, > > > Is that how the gdb/mi protocol is supposed to work or is that a bug or > > > missing feature in lldb-mi? > > > > > > > so the question is: is it enough to check that breakpoint was set to a > > > > selected target? > > > If that's just how the protocol works then we'll have to make do with > > > what we got. > > That's not "how the protocol works" in general. It's how lldb-mi behaves > > when it's control connection is closed. If you pipe its input from a file, > > lldb-mi will get an EOF as soon as it processes the last command, > > interpret that as the IDE closing the connection and exit (a perfectly > > reasonable behavior for its intended use case). So it will never get around > > to printing the breakpoint-hit message, because it will not wait long > > enough for that to happen. If you make sure the stdin does not get an EOF > > then (either by typing the same commands interactively, or by doing > > something like `cat break_insert.test - | lldb-mi`, you will see the "hit" > > message does get displayed (however, then the lldb-mi process will hang > > because it will expect more commands). > To make sure I understand your point: Does lldb-mi consumes input > asynchronously from its command handler, so for example, when sending the mi > equivalent of `b myFunc`, `r`, `p foo` — will lldb-mi wait until the > breakpoint is hit or the target is terminated before consuming the next > command after `r` or will it consume and attempt to execute `p foo` as soon > as possible and thus potentially before the breakpoint is hit? > > If this is the case, we could introduce a "synchronized" mode for testing > lldb-mi that behaves more like the SBAPI. Or we could pick up the idea you > mentioned a while ago and produce a separate lldb-mi test driver that can > send and get a reply for exactly one action at a time, similar to how the > SBAPI behaves. > To make sure I understand your point: Does lldb-mi consumes input > asynchronously from its command handler, so for example, when sending the mi > equivalent of b myFunc, r, p foo — will lldb-mi wait until the breakpoint is > hit or the target is terminated before consuming the next command after r or > will it consume and attempt to execute p foo as soon as possible and thus > potentially before the breakpoint is hit? I know very little about lldb-mi implementation or the gdb-mi protocol, but yes, that is what I think is happening. In general, you need the ability to issue asynchronous commands, if for nothing else, then to implement the equivalent of ^C. gdb-remote protocol also multiplexes reading from the socket and waiting on inferior state change for this reason (and would respond the same way if you tried to feed it input from a file). BTW: SB API also has an asynchronous mode, and I think it is even the default. It's just that we switch it to synchronous mode for testing, as one does not care about the ability to interrupt the process in tests (most of the time). > If this is the case, we could introduce a "synchronized" mode for testing > lldb-mi that behaves more like the SBAPI. Or we could pick up the idea you > mentioned a while ago and produce a separate lldb-mi test driver that can > send and get a reply for exactly one action at a time, similar to how the > SBAPI behaves. I think both of these are valid options. Probably the simplest way to implement the first one would be to introduce a `-wait-for-target-to-stop` command (maybe there is one already ??). The advantage of the second one is that we will have the ability to inject commands which depend on the results of previous commands (something that I think we will need, sooner or later). Repository: rL LLVM https://reviews.llvm.org/D46588 ___ lldb-commits mailing list lldb-commits@lists.llvm.org
[Lldb-commits] [PATCH] D46588: [LLDB][lldb-mi] Add possibility to set breakpoints without selecting a target.
aprantl added a comment. Alexander, I don't want this discussion to block you progress too much. It's important that we sort out the best way to test lldb-mi early on (and I hope this doesn't take too long), but while we are debating this you could also land the patch with the classic expect-based testcase that you had and go back and convert it later on. It's a bit more work, but converting the testcases shouldn't be too difficult. Repository: rL LLVM https://reviews.llvm.org/D46588 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D46934: Make ObjectFileMachO work on non-darwin platforms
labath added inline comments. Comment at: source/Plugins/Process/Utility/RegisterContextDarwin_arm.cpp:1037 SetError(set, Write, -1); -return KERN_INVALID_ARGUMENT; +return -1; } aprantl wrote: > Could we keep this as a local constant? > perhaps with an #ifndef KERN_INVALID_ARGUMENT clause? We could. I didn't do that originally, as `RegisterContextDarwin_x86_64::WriteGPR()` looks exactly like this function, and it uses `-1` already, but that works for me as well. https://reviews.llvm.org/D46934 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D46934: Make ObjectFileMachO work on non-darwin platforms
aprantl added inline comments. Comment at: source/Plugins/Process/Utility/RegisterContextDarwin_arm.cpp:1037 SetError(set, Write, -1); -return KERN_INVALID_ARGUMENT; +return -1; } Could we keep this as a local constant? perhaps with an #ifndef KERN_INVALID_ARGUMENT clause? https://reviews.llvm.org/D46934 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D46588: [LLDB][lldb-mi] Add possibility to set breakpoints without selecting a target.
aprantl added inline comments. Comment at: lit/tools/lldb-mi/breakpoint/break-insert.test:14 +# CHECK-AFTER: ^running +# CHECK-AFTER: *stopped,reason="breakpoint-hit" + labath wrote: > aprantl wrote: > > polyakov.alex wrote: > > > aprantl wrote: > > > > CHECK-AFTER is not recognized by FileCheck: > > > > > > > > https://www.llvm.org/docs/CommandGuide/FileCheck.html > > > > > > > > You probably saw this in a testcase that ran FileCheck twice, one time > > > > with the CHECK prefix and once with a custom > > > > `--check-prefix=CHECK-AFTER` which is a common trick to have more than > > > > one set of FileCheck directives in a single file. > > > Yes. There is no problem to write test using only `CHECK` and > > > `CHECK-NOT`, but as I said, in lldb-mi's output we can't find any info > > > about hitting breakpoint, so the question is: is it enough to check that > > > breakpoint was set to a selected target? > > > in lldb-mi's output we can't find any info about hitting breakpoint, > > Is that how the gdb/mi protocol is supposed to work or is that a bug or > > missing feature in lldb-mi? > > > > > so the question is: is it enough to check that breakpoint was set to a > > > selected target? > > If that's just how the protocol works then we'll have to make do with what > > we got. > That's not "how the protocol works" in general. It's how lldb-mi behaves when > it's control connection is closed. If you pipe its input from a file, lldb-mi > will get an EOF as soon as it processes the last command, interpret that as > the IDE closing the connection and exit (a perfectly reasonable behavior for > its intended use case). So it will never get around to printing the > breakpoint-hit message, because it will not wait long enough for that to > happen. If you make sure the stdin does not get an EOF then (either by typing > the same commands interactively, or by doing something like `cat > break_insert.test - | lldb-mi`, you will see the "hit" message does get > displayed (however, then the lldb-mi process will hang because it will expect > more commands). To make sure I understand your point: Does lldb-mi consumes input asynchronously from its command handler, so for example, when sending the mi equivalent of `b myFunc`, `r`, `p foo` — will lldb-mi wait until the breakpoint is hit or the target is terminated before consuming the next command after `r` or will it consume and attempt to execute `p foo` as soon as possible and thus potentially before the breakpoint is hit? If this is the case, we could introduce a "synchronized" mode for testing lldb-mi that behaves more like the SBAPI. Or we could pick up the idea you mentioned a while ago and produce a separate lldb-mi test driver that can send and get a reply for exactly one action at a time, similar to how the SBAPI behaves. Repository: rL LLVM https://reviews.llvm.org/D46588 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D46885: Remove append parameter to FindGlobalVariables
tromey added a comment. I don't have commit access, so could someone please land this for me? https://reviews.llvm.org/D46885 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D46934: Make ObjectFileMachO work on non-darwin platforms
labath created this revision.
labath added reviewers: jasonmolenda, aprantl, clayborg.
Herald added subscribers: kristof.beyls, mgorny.
Herald added a reviewer: javed.absar.
Before this patch we were unable to write cross-platform MachO tests
because the parsing code did not compile on other platforms. The reason
for that was that ObjectFileMachO depended on
RegisterContextDarwin_arm(64)? (presumably for core file parsing) and
the two Register Context classes uses constants from the system headers
(KERN_SUCCESS, KERN_INVALID_ARGUMENT).
As far as I can tell, these two files don't actually interact with the
darwin kernel -- they are used only in ObjectFileMachO and MacOSX-Kernel
process plugin (even though it has "kernel" in the name, this one
communicates with it via network packets and not syscalls). So there is
no good reason to use os-specific error codes here. In fact, the
RegisterContextDarwin_i386/x86_64 classes and the code which uses them
already use 0/-1 constants for these purposes, so changing the arm
context to do the same makes the code more consistent.
This is the only change necessary (apart from build system glue) to make
ObjectFileMachO work on other platforms. To demonstrate that, I remove
REQUIRES:darwin from our (only) cross-platform mach-o test.
https://reviews.llvm.org/D46934
Files:
lit/Modules/lc_version_min.yaml
source/Initialization/CMakeLists.txt
source/Initialization/SystemInitializerCommon.cpp
source/Plugins/Process/Utility/RegisterContextDarwin_arm.cpp
source/Plugins/Process/Utility/RegisterContextDarwin_arm64.cpp
Index: source/Plugins/Process/Utility/RegisterContextDarwin_arm64.cpp
===
--- source/Plugins/Process/Utility/RegisterContextDarwin_arm64.cpp
+++ source/Plugins/Process/Utility/RegisterContextDarwin_arm64.cpp
@@ -8,15 +8,8 @@
//
//===--===//
-#if defined(__APPLE__)
-
#include "RegisterContextDarwin_arm64.h"
-// C Includes
-#include
-#include
-#include
-
// C++ Includes
// Other libraries and framework includes
#include "lldb/Core/RegisterValue.h"
@@ -221,7 +214,7 @@
int set = GPRRegSet;
if (!RegisterSetIsCached(set)) {
SetError(set, Write, -1);
-return KERN_INVALID_ARGUMENT;
+return -1;
}
SetError(set, Write, DoWriteGPR(GetThreadID(), set, gpr));
SetError(set, Read, -1);
@@ -232,7 +225,7 @@
int set = FPURegSet;
if (!RegisterSetIsCached(set)) {
SetError(set, Write, -1);
-return KERN_INVALID_ARGUMENT;
+return -1;
}
SetError(set, Write, DoWriteFPU(GetThreadID(), set, fpu));
SetError(set, Read, -1);
@@ -243,7 +236,7 @@
int set = EXCRegSet;
if (!RegisterSetIsCached(set)) {
SetError(set, Write, -1);
-return KERN_INVALID_ARGUMENT;
+return -1;
}
SetError(set, Write, DoWriteEXC(GetThreadID(), set, exc));
SetError(set, Read, -1);
@@ -254,7 +247,7 @@
int set = DBGRegSet;
if (!RegisterSetIsCached(set)) {
SetError(set, Write, -1);
-return KERN_INVALID_ARGUMENT;
+return -1;
}
SetError(set, Write, DoWriteDBG(GetThreadID(), set, dbg));
SetError(set, Read, -1);
@@ -274,7 +267,7 @@
default:
break;
}
- return KERN_INVALID_ARGUMENT;
+ return -1;
}
int RegisterContextDarwin_arm64::WriteRegisterSet(uint32_t set) {
@@ -293,7 +286,7 @@
break;
}
}
- return KERN_INVALID_ARGUMENT;
+ return -1;
}
void RegisterContextDarwin_arm64::LogDBGRegisters(Log *log, const DBG ) {
@@ -313,7 +306,7 @@
if (set == -1)
return false;
- if (ReadRegisterSet(set, false) != KERN_SUCCESS)
+ if (ReadRegisterSet(set, false) != 0)
return false;
switch (reg) {
@@ -545,7 +538,7 @@
if (set == -1)
return false;
- if (ReadRegisterSet(set, false) != KERN_SUCCESS)
+ if (ReadRegisterSet(set, false) != 0)
return false;
switch (reg) {
@@ -642,14 +635,14 @@
default:
return false;
}
- return WriteRegisterSet(set) == KERN_SUCCESS;
+ return WriteRegisterSet(set) == 0;
}
bool RegisterContextDarwin_arm64::ReadAllRegisterValues(
lldb::DataBufferSP _sp) {
data_sp.reset(new DataBufferHeap(REG_CONTEXT_SIZE, 0));
- if (data_sp && ReadGPR(false) == KERN_SUCCESS &&
- ReadFPU(false) == KERN_SUCCESS && ReadEXC(false) == KERN_SUCCESS) {
+ if (data_sp && ReadGPR(false) == 0 && ReadFPU(false) == 0 &&
+ ReadEXC(false) == 0) {
uint8_t *dst = data_sp->GetBytes();
::memcpy(dst, , sizeof(gpr));
dst += sizeof(gpr);
@@ -675,11 +668,11 @@
::memcpy(, src, sizeof(exc));
uint32_t success_count = 0;
-if (WriteGPR() == KERN_SUCCESS)
+if (WriteGPR() == 0)
++success_count;
-if (WriteFPU() == KERN_SUCCESS)
+if (WriteFPU() == 0)
++success_count;
-if (WriteEXC() == KERN_SUCCESS)
+if (WriteEXC() == 0)
++success_count;
return success_count == 3;
}
@@ -980,7 +973,7 @@
// Read the debug state
int
[Lldb-commits] [PATCH] D46888: [DWARF] Have HashedNameToDIE store a DataExtractor by value
JDevlieghere accepted this revision. JDevlieghere added a comment. This revision is now accepted and ready to land. LGTM https://reviews.llvm.org/D46888 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D46588: [LLDB][lldb-mi] Add possibility to set breakpoints without selecting a target.
labath added inline comments. Comment at: lit/tools/lldb-mi/breakpoint/break-insert.test:14 +# CHECK-AFTER: ^running +# CHECK-AFTER: *stopped,reason="breakpoint-hit" + aprantl wrote: > polyakov.alex wrote: > > aprantl wrote: > > > CHECK-AFTER is not recognized by FileCheck: > > > > > > https://www.llvm.org/docs/CommandGuide/FileCheck.html > > > > > > You probably saw this in a testcase that ran FileCheck twice, one time > > > with the CHECK prefix and once with a custom `--check-prefix=CHECK-AFTER` > > > which is a common trick to have more than one set of FileCheck directives > > > in a single file. > > Yes. There is no problem to write test using only `CHECK` and `CHECK-NOT`, > > but as I said, in lldb-mi's output we can't find any info about hitting > > breakpoint, so the question is: is it enough to check that breakpoint was > > set to a selected target? > > in lldb-mi's output we can't find any info about hitting breakpoint, > Is that how the gdb/mi protocol is supposed to work or is that a bug or > missing feature in lldb-mi? > > > so the question is: is it enough to check that breakpoint was set to a > > selected target? > If that's just how the protocol works then we'll have to make do with what we > got. That's not "how the protocol works" in general. It's how lldb-mi behaves when it's control connection is closed. If you pipe its input from a file, lldb-mi will get an EOF as soon as it processes the last command, interpret that as the IDE closing the connection and exit (a perfectly reasonable behavior for its intended use case). So it will never get around to printing the breakpoint-hit message, because it will not wait long enough for that to happen. If you make sure the stdin does not get an EOF then (either by typing the same commands interactively, or by doing something like `cat break_insert.test - | lldb-mi`, you will see the "hit" message does get displayed (however, then the lldb-mi process will hang because it will expect more commands). Repository: rL LLVM https://reviews.llvm.org/D46588 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
