[Lldb-commits] [PATCH] D49739: [WIP] Re-implement MI target-select command.
labath added inline comments.
Comment at: lit/lit.cfg:59
-debugserver = lit.util.which('debugserver', lldb_tools_dir)
+if platform.system() in ['Darwin']:
+debugserver = lit.util.which('debugserver', lldb_tools_dir)
apolyakov wrote:
> Do we have `debugserver` only on macOS? On other OS it's called `lldb-server`?
That is correct (well.. some platforms like FreeBSD and Windows have neither).
Comment at: lit/tools/lldb-mi/target/inputs/target-select-so-path.py:8-11
+def get_free_port():
+s = socket.socket()
+s.bind(('', 0))
+return s.getsockname()[1]
This is still racy, because the port can be snatched from under you between the
time you get the free port and the time when lldb-server binds to it. If this
was the only test doing it then it might be fine, but since this is going to be
running concurrently with other tests, all of which are fetching free ports,
the chances of that happening add up.
(Also, binding to the wildcard address will trigger a firewall popup on some
machines.)
Comment at: lit/tools/lldb-mi/target/inputs/target-select-so-path.py:25-26
+# Run debugserver, lldb-mi and FileCheck.
+debugserver_proc = subprocess.Popen(debugserver, shell=True)
+lldbmi_proc = subprocess.Popen(lldbmi, stdin=subprocess.PIPE,
+ stdout=subprocess.PIPE, shell=True)
Another race here: lldb-mi can attempt to connect before lldb-server has had a
chance to start listening. (That's another reason to implement the port
handshake, as it will serve as an synchronization point -- you get the port
number only after lldb-server has successfully started and set up it's socket).
https://reviews.llvm.org/D49739
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49831: Don't print two errors for unknown commands.
labath accepted this revision. labath added a comment. This revision is now accepted and ready to land. Looks good. It would be nice to mention the name of that other function in the commit message. https://reviews.llvm.org/D49831 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49334: [LLDB} Added syntax highlighting support
labath added a comment. Thanks for the explanation. This looks fine to me, though I would feel better if someone else gave it a look too. Comment at: source/Core/Highlighter.cpp:29 + if (!m_prefix.empty()) +s << lldb_utility::ansi::FormatAnsiTerminalCodes(m_prefix); + s << value; labath wrote: > This call isn't exactly cheap. Maybe you could just call the function once > during initialization and just store the result? extra semicolons Comment at: source/Core/Highlighter.cpp:34 + // Calculate how many bytes we have written. + return m_prefix.size() + value.size() + m_suffix.size(); +} teemperor wrote: > labath wrote: > > This isn't correct, as you're not writing m_prefix, but it's transmogrified > > version. Btw, do you really need this return value anyway? > Good catch. And the return value is just to make the SourceManager happy > which always returns the total amount of bytes written. I'm working on a > patch that will move all the 'written byte counting' in lldb into the Stream > class, but as of now that's how it works. That sounds like a good idea. When you do that, could you please refer to the llvm raw_ostream classes to see how they handle this. Long term, it would be great if we could replace lldb's classes with those, so I'd like to avoid diverging from them if possible. https://reviews.llvm.org/D49334 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49322: Narrow the CompletionRequest API to being append-only.
labath added a comment. The patch makes sense to me, though I can't say I'm that familiar with this code. The thing I'd really like to get rid of is the need to have `return request.GetNumberOfMatches();` everywhere, but that's a fight for another day.. Comment at: include/lldb/Utility/CompletionRequest.h:88-93 +// Filter out duplicates. +if (m_match_set.find(completion) != m_match_set.end()) + return; + +m_matches->AppendString(completion); +m_match_set.insert(completion); Slightly shorter and more efficient: `if (m_match_set.insert(completion).second) m_matches->AppendString(completion);` https://reviews.llvm.org/D49322 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49685: LLDB does not respect platform sysroot when loading core on Linux
labath added a comment. In https://reviews.llvm.org/D49685#1175413, @EugeneBi wrote: > In https://reviews.llvm.org/D49685#1174770, @labath wrote: > > > Could you also add a test for this? > > > I never ran LLDB tests, not sure where they are and what they are. > Also, how would you test that? I know now my open core dump works, but I > cannot share it. Good question. Is this functionality specific to shared libraries, or could it be used to locate the main exe too? If yes, then it should be sufficient to take one of the existing core&exe files we have, copy the exe into a path matching what the core file expects, set the sysroot, and make sure the exe gets found when we open up the core file. You can look at the existing tests in `test/testcases/functionalities/postmortem/elf-core` for examples. If not, then it might get trickier because we'll need new core files, and it's hard to generate small ones with shared libraries. https://reviews.llvm.org/D49685 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49739: [WIP] Re-implement MI target-select command.
apolyakov added inline comments.
Comment at: lit/tools/lldb-mi/target/inputs/target-select-so-path.py:8-11
+def get_free_port():
+s = socket.socket()
+s.bind(('', 0))
+return s.getsockname()[1]
labath wrote:
> This is still racy, because the port can be snatched from under you between
> the time you get the free port and the time when lldb-server binds to it. If
> this was the only test doing it then it might be fine, but since this is
> going to be running concurrently with other tests, all of which are fetching
> free ports, the chances of that happening add up.
>
> (Also, binding to the wildcard address will trigger a firewall popup on some
> machines.)
There is a problem with getting port from lldb-server. If we run `lldb-server
gdbserver --pipe 0 ocalhost:0`, it'll print port number to its stdout, but we
can't get it using pipes since to do this we need to wait until lldb-server
finishes that isn't what we want.
https://reviews.llvm.org/D49739
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49739: [WIP] Re-implement MI target-select command.
labath added inline comments.
Comment at: lit/tools/lldb-mi/target/inputs/target-select-so-path.py:8-11
+def get_free_port():
+s = socket.socket()
+s.bind(('', 0))
+return s.getsockname()[1]
apolyakov wrote:
> labath wrote:
> > This is still racy, because the port can be snatched from under you between
> > the time you get the free port and the time when lldb-server binds to it.
> > If this was the only test doing it then it might be fine, but since this is
> > going to be running concurrently with other tests, all of which are
> > fetching free ports, the chances of that happening add up.
> >
> > (Also, binding to the wildcard address will trigger a firewall popup on
> > some machines.)
> There is a problem with getting port from lldb-server. If we run `lldb-server
> gdbserver --pipe 0 ocalhost:0`, it'll print port number to its stdout, but we
> can't get it using pipes since to do this we need to wait until lldb-server
> finishes that isn't what we want.
Aha, I see. lldb-server does not really expect you to pass std file descriptor
as the --pipe argument. Normally you would create a separate fd and pass that
instead. Doing that from python is a bit icky, but doable:
```
(r, w) = os.pipe()
kwargs = {}
if sys.version_info >= (3,0):
kwargs["pass_fds"] = [w]
llgs = subprocess.Popen(["lldb-server", "gdbserver", "--pipe", str(w), ...],
**kwargs)
port_bytes = os.read(r, 10)
port = int(port_bytes.decode("utf-8").strip('\x00'))
```
Alternatively, we could modify lldb-server to print the port number to stdout
in addition to any --pipe arguments (sounds like a good addition anyway, as it
enables easy free port selection for a shell user), and then you can sniff that
text from here.
https://reviews.llvm.org/D49739
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49776: Update framework-header-fix to force system sed
kastiglione accepted this revision. kastiglione added a comment. This revision is now accepted and ready to land. LGTM https://reviews.llvm.org/D49776 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49739: [WIP] Re-implement MI target-select command.
apolyakov added inline comments.
Comment at: lit/tools/lldb-mi/target/inputs/target-select-so-path.py:8-11
+def get_free_port():
+s = socket.socket()
+s.bind(('', 0))
+return s.getsockname()[1]
labath wrote:
> apolyakov wrote:
> > labath wrote:
> > > This is still racy, because the port can be snatched from under you
> > > between the time you get the free port and the time when lldb-server
> > > binds to it. If this was the only test doing it then it might be fine,
> > > but since this is going to be running concurrently with other tests, all
> > > of which are fetching free ports, the chances of that happening add up.
> > >
> > > (Also, binding to the wildcard address will trigger a firewall popup on
> > > some machines.)
> > There is a problem with getting port from lldb-server. If we run
> > `lldb-server gdbserver --pipe 0 ocalhost:0`, it'll print port number to its
> > stdout, but we can't get it using pipes since to do this we need to wait
> > until lldb-server finishes that isn't what we want.
> Aha, I see. lldb-server does not really expect you to pass std file
> descriptor as the --pipe argument. Normally you would create a separate fd
> and pass that instead. Doing that from python is a bit icky, but doable:
> ```
> (r, w) = os.pipe()
> kwargs = {}
> if sys.version_info >= (3,0):
> kwargs["pass_fds"] = [w]
> llgs = subprocess.Popen(["lldb-server", "gdbserver", "--pipe", str(w), ...],
> **kwargs)
> port_bytes = os.read(r, 10)
> port = int(port_bytes.decode("utf-8").strip('\x00'))
> ```
>
> Alternatively, we could modify lldb-server to print the port number to stdout
> in addition to any --pipe arguments (sounds like a good addition anyway, as
> it enables easy free port selection for a shell user), and then you can sniff
> that text from here.
`--pipe 0` prints port number exactly to stdout, so there will not be a
difference for us. It's not so simple to get port from lldb-server's stdout in
python, so I don't think it will save us.
https://reviews.llvm.org/D49739
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49739: [WIP] Re-implement MI target-select command.
labath added inline comments.
Comment at: lit/tools/lldb-mi/target/inputs/target-select-so-path.py:8-11
+def get_free_port():
+s = socket.socket()
+s.bind(('', 0))
+return s.getsockname()[1]
apolyakov wrote:
> labath wrote:
> > apolyakov wrote:
> > > labath wrote:
> > > > This is still racy, because the port can be snatched from under you
> > > > between the time you get the free port and the time when lldb-server
> > > > binds to it. If this was the only test doing it then it might be fine,
> > > > but since this is going to be running concurrently with other tests,
> > > > all of which are fetching free ports, the chances of that happening add
> > > > up.
> > > >
> > > > (Also, binding to the wildcard address will trigger a firewall popup on
> > > > some machines.)
> > > There is a problem with getting port from lldb-server. If we run
> > > `lldb-server gdbserver --pipe 0 ocalhost:0`, it'll print port number to
> > > its stdout, but we can't get it using pipes since to do this we need to
> > > wait until lldb-server finishes that isn't what we want.
> > Aha, I see. lldb-server does not really expect you to pass std file
> > descriptor as the --pipe argument. Normally you would create a separate fd
> > and pass that instead. Doing that from python is a bit icky, but doable:
> > ```
> > (r, w) = os.pipe()
> > kwargs = {}
> > if sys.version_info >= (3,0):
> > kwargs["pass_fds"] = [w]
> > llgs = subprocess.Popen(["lldb-server", "gdbserver", "--pipe", str(w),
> > ...], **kwargs)
> > port_bytes = os.read(r, 10)
> > port = int(port_bytes.decode("utf-8").strip('\x00'))
> > ```
> >
> > Alternatively, we could modify lldb-server to print the port number to
> > stdout in addition to any --pipe arguments (sounds like a good addition
> > anyway, as it enables easy free port selection for a shell user), and then
> > you can sniff that text from here.
> `--pipe 0` prints port number exactly to stdout, so there will not be a
> difference for us. It's not so simple to get port from lldb-server's stdout
> in python, so I don't think it will save us.
I think you're looking for this:
```
foo = subprocess.Popen(...)
print "The first line of output is: " + foo.stdout.readline()
```
Btw, using `--pipe 0` works only by accident (0 is the stdin descriptor), and
probably only in a terminal. Once popen() starts redirecting things, `0` will
probably not refer to the thing that `stdout` will read from. `--pipe 1` would
fix that, but then we have the issue that lldb-server will close the `--pipe`
descriptor once it's finished writing the port. That can have surprising
effects as subsequent attempts to write to stdout will fail. (That's why I
suggested a different implementation. Among other things, outputting something
like "lldb-server listening on 127.0.0.1:4747" will make it easier to separate
out the port from other things that lldb-server happens to write to stdout.)
https://reviews.llvm.org/D49739
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49739: [WIP] Re-implement MI target-select command.
apolyakov added inline comments.
Comment at: lit/tools/lldb-mi/target/inputs/target-select-so-path.py:8-11
+def get_free_port():
+s = socket.socket()
+s.bind(('', 0))
+return s.getsockname()[1]
labath wrote:
> apolyakov wrote:
> > labath wrote:
> > > apolyakov wrote:
> > > > labath wrote:
> > > > > This is still racy, because the port can be snatched from under you
> > > > > between the time you get the free port and the time when lldb-server
> > > > > binds to it. If this was the only test doing it then it might be
> > > > > fine, but since this is going to be running concurrently with other
> > > > > tests, all of which are fetching free ports, the chances of that
> > > > > happening add up.
> > > > >
> > > > > (Also, binding to the wildcard address will trigger a firewall popup
> > > > > on some machines.)
> > > > There is a problem with getting port from lldb-server. If we run
> > > > `lldb-server gdbserver --pipe 0 ocalhost:0`, it'll print port number to
> > > > its stdout, but we can't get it using pipes since to do this we need to
> > > > wait until lldb-server finishes that isn't what we want.
> > > Aha, I see. lldb-server does not really expect you to pass std file
> > > descriptor as the --pipe argument. Normally you would create a separate
> > > fd and pass that instead. Doing that from python is a bit icky, but
> > > doable:
> > > ```
> > > (r, w) = os.pipe()
> > > kwargs = {}
> > > if sys.version_info >= (3,0):
> > > kwargs["pass_fds"] = [w]
> > > llgs = subprocess.Popen(["lldb-server", "gdbserver", "--pipe", str(w),
> > > ...], **kwargs)
> > > port_bytes = os.read(r, 10)
> > > port = int(port_bytes.decode("utf-8").strip('\x00'))
> > > ```
> > >
> > > Alternatively, we could modify lldb-server to print the port number to
> > > stdout in addition to any --pipe arguments (sounds like a good addition
> > > anyway, as it enables easy free port selection for a shell user), and
> > > then you can sniff that text from here.
> > `--pipe 0` prints port number exactly to stdout, so there will not be a
> > difference for us. It's not so simple to get port from lldb-server's stdout
> > in python, so I don't think it will save us.
> I think you're looking for this:
> ```
> foo = subprocess.Popen(...)
> print "The first line of output is: " + foo.stdout.readline()
> ```
>
> Btw, using `--pipe 0` works only by accident (0 is the stdin descriptor), and
> probably only in a terminal. Once popen() starts redirecting things, `0` will
> probably not refer to the thing that `stdout` will read from. `--pipe 1`
> would fix that, but then we have the issue that lldb-server will close the
> `--pipe` descriptor once it's finished writing the port. That can have
> surprising effects as subsequent attempts to write to stdout will fail.
> (That's why I suggested a different implementation. Among other things,
> outputting something like "lldb-server listening on 127.0.0.1:4747" will make
> it easier to separate out the port from other things that lldb-server happens
> to write to stdout.)
> I think you're looking for this:
>
> foo = subprocess.Popen(...)
> print "The first line of output is: " + foo.stdout.readline()
I tried this, it hangs for me.
https://reviews.llvm.org/D49739
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49831: Don't print two errors for unknown commands.
This revision was automatically updated to reflect the committed changes.
Closed by commit rL338040: Don't print two errors for unknown commands.
(authored by teemperor, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D49831?vs=157415&id=157509#toc
Repository:
rL LLVM
https://reviews.llvm.org/D49831
Files:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/.categories
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
lldb/trunk/source/Interpreter/CommandInterpreter.cpp
Index:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
===
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
@@ -0,0 +1,39 @@
+"""
+Test how lldb reacts to wrong commands
+"""
+
+from __future__ import print_function
+
+import os
+import time
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class UnknownCommandTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@no_debug_info_test
+def test_ambiguous_command(self):
+command_interpreter = self.dbg.GetCommandInterpreter()
+self.assertTrue(command_interpreter, VALID_COMMAND_INTERPRETER)
+result = lldb.SBCommandReturnObject()
+
+command_interpreter.HandleCommand("g", result)
+self.assertFalse(result.Succeeded())
+self.assertRegexpMatches(result.GetError(), "Ambiguous command 'g'.
Possible matches:")
+self.assertRegexpMatches(result.GetError(), "gui")
+self.assertRegexpMatches(result.GetError(), "gdb-remote")
+# FIXME: Somehow we get 'gui' and 'gdb-remote' twice in the output.
+
+@no_debug_info_test
+def test_unknown_command(self):
+command_interpreter = self.dbg.GetCommandInterpreter()
+self.assertTrue(command_interpreter, VALID_COMMAND_INTERPRETER)
+result = lldb.SBCommandReturnObject()
+
+command_interpreter.HandleCommand("qbert", result)
+self.assertFalse(result.Succeeded())
+self.assertEquals(result.GetError(), "error: 'qbert' is not a valid
command.\n")
Index:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/.categories
===
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/.categories
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/.categories
@@ -0,0 +1 @@
+cmdline
Index: lldb/trunk/source/Interpreter/CommandInterpreter.cpp
===
--- lldb/trunk/source/Interpreter/CommandInterpreter.cpp
+++ lldb/trunk/source/Interpreter/CommandInterpreter.cpp
@@ -1693,33 +1693,6 @@
remainder.c_str());
cmd_obj->Execute(remainder.c_str(), result);
- } else {
-// We didn't find the first command object, so complete the first argument.
-Args command_args(command_string);
-StringList matches;
-unsigned cursor_char_position = strlen(command_args.GetArgumentAtIndex(0));
-CompletionRequest request(command_line, cursor_char_position, 0, -1,
- matches);
-int num_matches = HandleCompletionMatches(request);
-
-if (num_matches > 0) {
- std::string error_msg;
- error_msg.assign("ambiguous command '");
- error_msg.append(command_args.GetArgumentAtIndex(0));
- error_msg.append("'.");
-
- error_msg.append(" Possible completions:");
- for (int i = 0; i < num_matches; i++) {
-error_msg.append("\n\t");
-error_msg.append(matches.GetStringAtIndex(i));
- }
- error_msg.append("\n");
- result.AppendRawError(error_msg.c_str());
-} else
- result.AppendErrorWithFormat("Unrecognized command '%s'.\n",
- command_args.GetArgumentAtIndex(0));
-
-result.SetStatus(eReturnStatusFailed);
}
if (log)
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
@@ -0,0 +1,39 @@
+"""
+Test how lldb reacts to wrong commands
+"""
+
+from __future__ import print_function
+
+import os
+import time
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class UnknownCommandTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@no_d
[Lldb-commits] [lldb] r338040 - Don't print two errors for unknown commands.
Author: teemperor
Date: Thu Jul 26 09:32:05 2018
New Revision: 338040
URL: http://llvm.org/viewvc/llvm-project?rev=338040&view=rev
Log:
Don't print two errors for unknown commands.
Summary:
We always print two error messages when we hit an unknown command. As the
function
`CommandInterpreter::HandleCommand` that prints the second error message
unconditionally called the `CommandInterpreter::ResolveCommandImpl` before
(which prints the first error message), we can just remove
that second error message.
Fixes https://bugs.llvm.org/show_bug.cgi?id=38312
Reviewers: labath
Reviewed By: labath
Subscribers: labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D49831
Added:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/.categories
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
Modified:
lldb/trunk/source/Interpreter/CommandInterpreter.cpp
Added:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/.categories
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/.categories?rev=338040&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/.categories
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/.categories
Thu Jul 26 09:32:05 2018
@@ -0,0 +1 @@
+cmdline
Added:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py?rev=338040&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
Thu Jul 26 09:32:05 2018
@@ -0,0 +1,39 @@
+"""
+Test how lldb reacts to wrong commands
+"""
+
+from __future__ import print_function
+
+import os
+import time
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class UnknownCommandTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@no_debug_info_test
+def test_ambiguous_command(self):
+command_interpreter = self.dbg.GetCommandInterpreter()
+self.assertTrue(command_interpreter, VALID_COMMAND_INTERPRETER)
+result = lldb.SBCommandReturnObject()
+
+command_interpreter.HandleCommand("g", result)
+self.assertFalse(result.Succeeded())
+self.assertRegexpMatches(result.GetError(), "Ambiguous command 'g'.
Possible matches:")
+self.assertRegexpMatches(result.GetError(), "gui")
+self.assertRegexpMatches(result.GetError(), "gdb-remote")
+# FIXME: Somehow we get 'gui' and 'gdb-remote' twice in the output.
+
+@no_debug_info_test
+def test_unknown_command(self):
+command_interpreter = self.dbg.GetCommandInterpreter()
+self.assertTrue(command_interpreter, VALID_COMMAND_INTERPRETER)
+result = lldb.SBCommandReturnObject()
+
+command_interpreter.HandleCommand("qbert", result)
+self.assertFalse(result.Succeeded())
+self.assertEquals(result.GetError(), "error: 'qbert' is not a valid
command.\n")
Modified: lldb/trunk/source/Interpreter/CommandInterpreter.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/CommandInterpreter.cpp?rev=338040&r1=338039&r2=338040&view=diff
==
--- lldb/trunk/source/Interpreter/CommandInterpreter.cpp (original)
+++ lldb/trunk/source/Interpreter/CommandInterpreter.cpp Thu Jul 26 09:32:05
2018
@@ -1693,33 +1693,6 @@ bool CommandInterpreter::HandleCommand(c
remainder.c_str());
cmd_obj->Execute(remainder.c_str(), result);
- } else {
-// We didn't find the first command object, so complete the first argument.
-Args command_args(command_string);
-StringList matches;
-unsigned cursor_char_position = strlen(command_args.GetArgumentAtIndex(0));
-CompletionRequest request(command_line, cursor_char_position, 0, -1,
- matches);
-int num_matches = HandleCompletionMatches(request);
-
-if (num_matches > 0) {
- std::string error_msg;
- error_msg.assign("ambiguous command '");
- error_msg.append(command_args.GetArgumentAtIndex(0));
- error_msg.append("'.");
-
- error_msg.append(" Possible completions:");
- for (int i = 0; i < num_matches; i++) {
-error_msg.append("\n\t");
-error_msg.append(matches.GetStringAtIndex(
[Lldb-commits] [PATCH] D49739: [WIP] Re-implement MI target-select command.
apolyakov updated this revision to Diff 157512.
apolyakov added a comment.
Now tcp port is choosing by debugserver.
https://reviews.llvm.org/D49739
Files:
include/lldb/API/SBTarget.h
lit/lit.cfg
lit/tools/lldb-mi/target/inputs/main.c
lit/tools/lldb-mi/target/inputs/target-select-so-path.py
lit/tools/lldb-mi/target/lit.local.cfg
lit/tools/lldb-mi/target/target-select-so-path.test
source/API/SBTarget.cpp
tools/lldb-mi/MICmdCmdTarget.cpp
Index: tools/lldb-mi/MICmdCmdTarget.cpp
===
--- tools/lldb-mi/MICmdCmdTarget.cpp
+++ tools/lldb-mi/MICmdCmdTarget.cpp
@@ -10,9 +10,8 @@
// Overview:CMICmdCmdTargetSelect implementation.
// Third Party Headers:
-#include "lldb/API/SBCommandInterpreter.h"
-#include "lldb/API/SBCommandReturnObject.h"
#include "lldb/API/SBStream.h"
+#include "lldb/API/SBError.h"
// In-house headers:
#include "MICmdArgValNumber.h"
@@ -52,7 +51,7 @@
// Return: None.
// Throws: None.
//--
-CMICmdCmdTargetSelect::~CMICmdCmdTargetSelect() {}
+CMICmdCmdTargetSelect::~CMICmdCmdTargetSelect() = default;
//++
//
@@ -93,51 +92,44 @@
CMICmnLLDBDebugSessionInfo &rSessionInfo(
CMICmnLLDBDebugSessionInfo::Instance());
+ lldb::SBTarget target = rSessionInfo.GetTarget();
- // Check we have a valid target
- // Note: target created via 'file-exec-and-symbols' command
- if (!rSessionInfo.GetTarget().IsValid()) {
+ // Check we have a valid target.
+ // Note: target created via 'file-exec-and-symbols' command.
+ if (!target.IsValid()) {
SetError(CMIUtilString::Format(MIRSRC(IDS_CMD_ERR_INVALID_TARGET_CURRENT),
m_cmdData.strMiCmd.c_str()));
return MIstatus::failure;
}
- // Verify that we are executing remotely
+ // Verify that we are executing remotely.
const CMIUtilString &rRemoteType(pArgType->GetValue());
if (rRemoteType != "remote") {
SetError(CMIUtilString::Format(MIRSRC(IDS_CMD_ERR_INVALID_TARGET_TYPE),
m_cmdData.strMiCmd.c_str(),
rRemoteType.c_str()));
return MIstatus::failure;
}
- // Create a URL pointing to the remote gdb stub
+ // Create a URL pointing to the remote gdb stub.
const CMIUtilString strUrl =
CMIUtilString::Format("connect://%s", pArgParameters->GetValue().c_str());
- // Ask LLDB to connect to the target port
- const char *pPlugin("gdb-remote");
lldb::SBError error;
- lldb::SBProcess process = rSessionInfo.GetTarget().ConnectRemote(
+ // Ask LLDB to connect to the target port.
+ const char *pPlugin("gdb-remote");
+ lldb::SBProcess process = target.ConnectRemote(
rSessionInfo.GetListener(), strUrl.c_str(), pPlugin, error);
- // Verify that we have managed to connect successfully
- lldb::SBStream errMsg;
- error.GetDescription(errMsg);
+ // Verify that we have managed to connect successfully.
if (!process.IsValid()) {
SetError(CMIUtilString::Format(MIRSRC(IDS_CMD_ERR_INVALID_TARGET_PLUGIN),
m_cmdData.strMiCmd.c_str(),
- errMsg.GetData()));
-return MIstatus::failure;
- }
- if (error.Fail()) {
-SetError(CMIUtilString::Format(MIRSRC(IDS_CMD_ERR_CONNECT_TO_TARGET),
- m_cmdData.strMiCmd.c_str(),
- errMsg.GetData()));
+ error.GetCString()));
return MIstatus::failure;
}
- // Set the environment path if we were given one
+ // Set the environment path if we were given one.
CMIUtilString strWkDir;
if (rSessionInfo.SharedDataRetrieve(
rSessionInfo.m_constStrSharedDataKeyWkDir, strWkDir)) {
@@ -150,28 +142,13 @@
}
}
- // Set the shared object path if we were given one
+ // Set the shared object path if we were given one.
CMIUtilString strSolibPath;
if (rSessionInfo.SharedDataRetrieve(
- rSessionInfo.m_constStrSharedDataSolibPath, strSolibPath)) {
-lldb::SBDebugger &rDbgr = rSessionInfo.GetDebugger();
-lldb::SBCommandInterpreter cmdIterpreter = rDbgr.GetCommandInterpreter();
-
-CMIUtilString strCmdString = CMIUtilString::Format(
-"target modules search-paths add . %s", strSolibPath.c_str());
-
-lldb::SBCommandReturnObject retObj;
-cmdIterpreter.HandleCommand(strCmdString.c_str(), retObj, false);
+ rSessionInfo.m_constStrSharedDataSolibPath, strSolibPath))
+target.AppendImageSearchPath(".", strSolibPath.c_str(), error);
-if (!retObj.Succeeded()) {
- SetError(CMIUtilString::Format(MIRSRC(IDS_CMD_ERR_FNFAILED),
- m_cmdData.strMiCmd.c_str(),
- "target-select"));
- return MIstatus::failure;
-}
- }
-
- return MIstatus::success;
+ return HandleSBE
[Lldb-commits] [PATCH] D49866: Fix duplicate suggestions after an ambiguous command
teemperor created this revision.
So far lldb is printing this when it finds an ambiguous command:
(lldb) g
Ambiguous command 'g'. Possible matches:
gdb-remote
gui
gdb-remote
gui
The duplicates come from the fact that we call the same query twice with the
same parameters
and add it to the same list. This patch just removes the second query call to
`GetCommandObject`.
As `GetCommandObject` is const and the name parameter is also not modified,
this shouldn't break
anything else. I didn't merge the remaining if statement into the else as I
think otherwise the
`if obj==nullptr do X else Y` pattern in there becomes hard to recognize.
https://reviews.llvm.org/D49866
Files:
packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
source/Interpreter/CommandInterpreter.cpp
Index: source/Interpreter/CommandInterpreter.cpp
===
--- source/Interpreter/CommandInterpreter.cpp
+++ source/Interpreter/CommandInterpreter.cpp
@@ -2932,8 +2932,6 @@
actual_cmd_name_len = cmd_obj->GetCommandName().size();
}
} else {
-if (!cmd_obj)
- cmd_obj = GetCommandObject(next_word, &matches);
if (cmd_obj) {
llvm::StringRef cmd_name = cmd_obj->GetCommandName();
actual_cmd_name_len += cmd_name.size();
Index:
packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
===
---
packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
+++
packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
@@ -26,7 +26,7 @@
self.assertRegexpMatches(result.GetError(), "Ambiguous command 'g'.
Possible matches:")
self.assertRegexpMatches(result.GetError(), "gui")
self.assertRegexpMatches(result.GetError(), "gdb-remote")
-# FIXME: Somehow we get 'gui' and 'gdb-remote' twice in the output.
+self.assertEquals(1, result.GetError().count("gdb-remote"))
@no_debug_info_test
def test_unknown_command(self):
Index: source/Interpreter/CommandInterpreter.cpp
===
--- source/Interpreter/CommandInterpreter.cpp
+++ source/Interpreter/CommandInterpreter.cpp
@@ -2932,8 +2932,6 @@
actual_cmd_name_len = cmd_obj->GetCommandName().size();
}
} else {
-if (!cmd_obj)
- cmd_obj = GetCommandObject(next_word, &matches);
if (cmd_obj) {
llvm::StringRef cmd_name = cmd_obj->GetCommandName();
actual_cmd_name_len += cmd_name.size();
Index: packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
===
--- packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
+++ packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
@@ -26,7 +26,7 @@
self.assertRegexpMatches(result.GetError(), "Ambiguous command 'g'. Possible matches:")
self.assertRegexpMatches(result.GetError(), "gui")
self.assertRegexpMatches(result.GetError(), "gdb-remote")
-# FIXME: Somehow we get 'gui' and 'gdb-remote' twice in the output.
+self.assertEquals(1, result.GetError().count("gdb-remote"))
@no_debug_info_test
def test_unknown_command(self):
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49779: Make framework-header-fix process copied headers
xiaobai requested changes to this revision.
xiaobai added a comment.
This revision now requires changes to proceed.
I think this might actually not do what we want it to do. I've commented inline
with my concerns.
Comment at: cmake/modules/LLDBFramework.cmake:21
add_custom_command(TARGET lldb-framework POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
COMMAND ${CMAKE_COMMAND} -E create_symlink Versions/Current/Headers
${LLDB_FRAMEWORK_DIR}/LLDB.framework/Headers
keith wrote:
> xiaobai wrote:
> > This line shouldn't be necessary anymore then, right?
> It still is, the change below doesn't actually do the copying, it only runs
> the script on the location the headers have already been copied too.
Are you saying that it will fix the framework headers that have already been
copied? If so, then I don't think this will work, because the copy occurs after
lldb-framework has been built, and lldb-framework depends on
lldb-framework-headers.
Comment at: cmake/modules/LLDBFramework.cmake:41
+add_custom_target(lldb-framework-headers
+ DEPENDS ${framework_headers}
+ COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
This should not just depend on `framework_headers`, because those are in the
location `${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders`. You want to run the
script on `$/Headers`, which is not guaranteed to
exist or have been populated with headers when this actually gets run. See my
comment above.
https://reviews.llvm.org/D49779
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49866: Fix duplicate suggestions after an ambiguous command
davide accepted this revision. davide added a comment. This revision is now accepted and ready to land. LG. thanks for improving the interface, I think all these cleanups are really good. https://reviews.llvm.org/D49866 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r338043 - Fix duplicate suggestions after an ambiguous command
Author: teemperor
Date: Thu Jul 26 10:14:18 2018
New Revision: 338043
URL: http://llvm.org/viewvc/llvm-project?rev=338043&view=rev
Log:
Fix duplicate suggestions after an ambiguous command
Summary:
So far lldb is printing this when it finds an ambiguous command:
```
(lldb) g
Ambiguous command 'g'. Possible matches:
gdb-remote
gui
gdb-remote
gui
```
The duplicates come from the fact that we call the same query twice with the
same parameters
and add it to the same list. This patch just removes the second query call to
`GetCommandObject`.
As `GetCommandObject` is const and the name parameter is also not modified,
this shouldn't break
anything else. I didn't merge the remaining if statement into the else as I
think otherwise the
`if obj==nullptr do X else Y` pattern in there becomes hard to recognize.
Reviewers: davide
Reviewed By: davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D49866
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
lldb/trunk/source/Interpreter/CommandInterpreter.cpp
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py?rev=338043&r1=338042&r2=338043&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
Thu Jul 26 10:14:18 2018
@@ -26,7 +26,7 @@ class UnknownCommandTestCase(TestBase):
self.assertRegexpMatches(result.GetError(), "Ambiguous command 'g'.
Possible matches:")
self.assertRegexpMatches(result.GetError(), "gui")
self.assertRegexpMatches(result.GetError(), "gdb-remote")
-# FIXME: Somehow we get 'gui' and 'gdb-remote' twice in the output.
+self.assertEquals(1, result.GetError().count("gdb-remote"))
@no_debug_info_test
def test_unknown_command(self):
Modified: lldb/trunk/source/Interpreter/CommandInterpreter.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/CommandInterpreter.cpp?rev=338043&r1=338042&r2=338043&view=diff
==
--- lldb/trunk/source/Interpreter/CommandInterpreter.cpp (original)
+++ lldb/trunk/source/Interpreter/CommandInterpreter.cpp Thu Jul 26 10:14:18
2018
@@ -2932,8 +2932,6 @@ CommandInterpreter::ResolveCommandImpl(s
actual_cmd_name_len = cmd_obj->GetCommandName().size();
}
} else {
-if (!cmd_obj)
- cmd_obj = GetCommandObject(next_word, &matches);
if (cmd_obj) {
llvm::StringRef cmd_name = cmd_obj->GetCommandName();
actual_cmd_name_len += cmd_name.size();
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49866: Fix duplicate suggestions after an ambiguous command
This revision was automatically updated to reflect the committed changes.
Closed by commit rL338043: Fix duplicate suggestions after an ambiguous command
(authored by teemperor, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D49866?vs=157518&id=157524#toc
Repository:
rL LLVM
https://reviews.llvm.org/D49866
Files:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
lldb/trunk/source/Interpreter/CommandInterpreter.cpp
Index:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
===
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
@@ -26,7 +26,7 @@
self.assertRegexpMatches(result.GetError(), "Ambiguous command 'g'.
Possible matches:")
self.assertRegexpMatches(result.GetError(), "gui")
self.assertRegexpMatches(result.GetError(), "gdb-remote")
-# FIXME: Somehow we get 'gui' and 'gdb-remote' twice in the output.
+self.assertEquals(1, result.GetError().count("gdb-remote"))
@no_debug_info_test
def test_unknown_command(self):
Index: lldb/trunk/source/Interpreter/CommandInterpreter.cpp
===
--- lldb/trunk/source/Interpreter/CommandInterpreter.cpp
+++ lldb/trunk/source/Interpreter/CommandInterpreter.cpp
@@ -2932,8 +2932,6 @@
actual_cmd_name_len = cmd_obj->GetCommandName().size();
}
} else {
-if (!cmd_obj)
- cmd_obj = GetCommandObject(next_word, &matches);
if (cmd_obj) {
llvm::StringRef cmd_name = cmd_obj->GetCommandName();
actual_cmd_name_len += cmd_name.size();
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/wrong_commands/TestWrongCommands.py
@@ -26,7 +26,7 @@
self.assertRegexpMatches(result.GetError(), "Ambiguous command 'g'. Possible matches:")
self.assertRegexpMatches(result.GetError(), "gui")
self.assertRegexpMatches(result.GetError(), "gdb-remote")
-# FIXME: Somehow we get 'gui' and 'gdb-remote' twice in the output.
+self.assertEquals(1, result.GetError().count("gdb-remote"))
@no_debug_info_test
def test_unknown_command(self):
Index: lldb/trunk/source/Interpreter/CommandInterpreter.cpp
===
--- lldb/trunk/source/Interpreter/CommandInterpreter.cpp
+++ lldb/trunk/source/Interpreter/CommandInterpreter.cpp
@@ -2932,8 +2932,6 @@
actual_cmd_name_len = cmd_obj->GetCommandName().size();
}
} else {
-if (!cmd_obj)
- cmd_obj = GetCommandObject(next_word, &matches);
if (cmd_obj) {
llvm::StringRef cmd_name = cmd_obj->GetCommandName();
actual_cmd_name_len += cmd_name.size();
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49779: Make framework-header-fix process copied headers
keith updated this revision to Diff 157525.
keith added a comment.
- Make headers a post build command
https://reviews.llvm.org/D49779
Files:
cmake/modules/LLDBFramework.cmake
Index: cmake/modules/LLDBFramework.cmake
===
--- cmake/modules/LLDBFramework.cmake
+++ cmake/modules/LLDBFramework.cmake
@@ -12,9 +12,6 @@
COMMAND ${CMAKE_COMMAND} -E copy ${header}
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
list(APPEND framework_headers
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
endforeach()
-add_custom_target(lldb-framework-headers
- DEPENDS ${framework_headers}
- COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
${CMAKE_CURRENT_BINARY_DIR} ${LLDB_VERSION})
if (NOT IOS)
if (NOT LLDB_BUILT_STANDALONE)
@@ -40,6 +37,9 @@
LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_FRAMEWORK_INSTALL_DIR}
PUBLIC_HEADER "${framework_headers}")
+add_custom_command(TARGET lldb-framework POST_BUILD
+ COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
$/Headers ${LLDB_VERSION}
+)
+
add_dependencies(lldb-framework
- lldb-framework-headers
lldb-suite)
Index: cmake/modules/LLDBFramework.cmake
===
--- cmake/modules/LLDBFramework.cmake
+++ cmake/modules/LLDBFramework.cmake
@@ -12,9 +12,6 @@
COMMAND ${CMAKE_COMMAND} -E copy ${header} ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
list(APPEND framework_headers ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
endforeach()
-add_custom_target(lldb-framework-headers
- DEPENDS ${framework_headers}
- COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh ${CMAKE_CURRENT_BINARY_DIR} ${LLDB_VERSION})
if (NOT IOS)
if (NOT LLDB_BUILT_STANDALONE)
@@ -40,6 +37,9 @@
LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/${LLDB_FRAMEWORK_INSTALL_DIR}
PUBLIC_HEADER "${framework_headers}")
+add_custom_command(TARGET lldb-framework POST_BUILD
+ COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh $/Headers ${LLDB_VERSION}
+)
+
add_dependencies(lldb-framework
- lldb-framework-headers
lldb-suite)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49779: Make framework-header-fix process copied headers
keith added inline comments.
Comment at: cmake/modules/LLDBFramework.cmake:41
+add_custom_target(lldb-framework-headers
+ DEPENDS ${framework_headers}
+ COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
xiaobai wrote:
> This should not just depend on `framework_headers`, because those are in the
> location `${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders`. You want to run the
> script on `$/Headers`, which is not guaranteed to
> exist or have been populated with headers when this actually gets run. See my
> comment above.
Updated this by making it a POST_BUILD command instead
https://reviews.llvm.org/D49779
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49685: LLDB does not respect platform sysroot when loading core on Linux
EugeneBi added a comment. In https://reviews.llvm.org/D49685#1176399, @labath wrote: > In https://reviews.llvm.org/D49685#1175413, @EugeneBi wrote: > > > In https://reviews.llvm.org/D49685#1174770, @labath wrote: > > > > > Could you also add a test for this? > > > > > > I never ran LLDB tests, not sure where they are and what they are. > > Also, how would you test that? I know now my open core dump works, but I > > cannot share it. > > > Good question. Is this functionality specific to shared libraries, or could > it be used to locate the main exe too? > > If yes, then it should be sufficient to take one of the existing core&exe > files we have, copy the exe into a path matching what the core file expects, > set the sysroot, and make sure the exe gets found when we open up the core > file. You can look at the existing tests in > `test/testcases/functionalities/postmortem/elf-core` for examples. > > If not, then it might get trickier because we'll need new core files, and > it's hard to generate small ones with shared libraries. It is specific to shared libraries. Opening the executable and core dump follows different code path. https://reviews.llvm.org/D49685 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49779: Make framework-header-fix process copied headers
xiaobai added a comment.
Looks good
Comment at: cmake/modules/LLDBFramework.cmake:41
+add_custom_target(lldb-framework-headers
+ DEPENDS ${framework_headers}
+ COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
keith wrote:
> xiaobai wrote:
> > This should not just depend on `framework_headers`, because those are in
> > the location `${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders`. You want to
> > run the script on `$/Headers`, which is not
> > guaranteed to exist or have been populated with headers when this actually
> > gets run. See my comment above.
> Updated this by making it a POST_BUILD command instead
Can you combine this with the lldb-framework POST_BUILD above? After that this
should be good to go.
https://reviews.llvm.org/D49779
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49632: [lldb-mi] Re-implement MI HandleProcessEventStateSuspended.
apolyakov updated this revision to Diff 157533.
apolyakov retitled this revision from "[WIP] Re-implement MI
HandleProcessEventStateSuspended." to "[lldb-mi] Re-implement MI
HandleProcessEventStateSuspended.".
apolyakov added a comment.
It seems that it's impossible to get `HandleProcessEventStateSuspended` called
on Linux, so I've copied code of this patch into
`HandleProcessEventStateStopped` to check new output.
Was(`HandleCommand("process status")`):
~"Process 17065 stopped\n* thread #1, name = 'bash', stop reason = breakpoint
1.1\nframe #0: 0x0041eed0 bash`main\nbash`main:\n-> 0x41eed0 <+0>:
pushq %r15\n0x41eed2 <+2>: pushq %r14\n0x41eed4 <+4>: pushq %r13\n
0x41eed6 <+6>: pushq %r12\n"
Now(SB API):
SBProcess: pid = 17065, state = stopped, threads = 1, executable = bash
thread #1: tid = 17065, 0x0041eed0 bash`main, name = 'bash', stop
reason = breakpoint 1.1
Of course, it will be `state = suspended` in a "real life".
https://reviews.llvm.org/D49632
Files:
tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp
Index: tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp
===
--- tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp
+++ tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp
@@ -950,24 +950,26 @@
bool CMICmnLLDBDebuggerHandleEvents::HandleProcessEventStateSuspended(
const lldb::SBEvent &vEvent) {
bool bOk = MIstatus::success;
+ lldb::SBStream streamOut;
lldb::SBDebugger &rDebugger =
CMICmnLLDBDebugSessionInfo::Instance().GetDebugger();
lldb::SBProcess sbProcess =
CMICmnLLDBDebugSessionInfo::Instance().GetProcess();
lldb::SBTarget target = sbProcess.GetTarget();
if (rDebugger.GetSelectedTarget() == target) {
if (!UpdateSelectedThread())
return MIstatus::failure;
-
-lldb::SBCommandReturnObject result;
-const lldb::ReturnStatus status =
-rDebugger.GetCommandInterpreter().HandleCommand("process status",
-result, false);
-MIunused(status);
-bOk = TextToStderr(result.GetError());
-bOk = bOk && TextToStdout(result.GetOutput());
+sbProcess.GetDescription(streamOut);
+// Add a delimiter between process' and threads' info.
+streamOut.Printf("\n");
+for (uint32_t i = 0, e = sbProcess.GetNumThreads(); i < e; ++i) {
+ const lldb::SBThread thread = sbProcess.GetThreadAtIndex(i);
+ if (!thread.IsValid())
+continue;
+ thread.GetDescription(streamOut);
+}
+bOk = TextToStdout(streamOut.GetData());
} else {
-lldb::SBStream streamOut;
const MIuint nTargetIndex = rDebugger.GetIndexOfTarget(target);
if (nTargetIndex != UINT_MAX)
streamOut.Printf("Target %d: (", nTargetIndex);
Index: tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp
===
--- tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp
+++ tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp
@@ -950,24 +950,26 @@
bool CMICmnLLDBDebuggerHandleEvents::HandleProcessEventStateSuspended(
const lldb::SBEvent &vEvent) {
bool bOk = MIstatus::success;
+ lldb::SBStream streamOut;
lldb::SBDebugger &rDebugger =
CMICmnLLDBDebugSessionInfo::Instance().GetDebugger();
lldb::SBProcess sbProcess =
CMICmnLLDBDebugSessionInfo::Instance().GetProcess();
lldb::SBTarget target = sbProcess.GetTarget();
if (rDebugger.GetSelectedTarget() == target) {
if (!UpdateSelectedThread())
return MIstatus::failure;
-
-lldb::SBCommandReturnObject result;
-const lldb::ReturnStatus status =
-rDebugger.GetCommandInterpreter().HandleCommand("process status",
-result, false);
-MIunused(status);
-bOk = TextToStderr(result.GetError());
-bOk = bOk && TextToStdout(result.GetOutput());
+sbProcess.GetDescription(streamOut);
+// Add a delimiter between process' and threads' info.
+streamOut.Printf("\n");
+for (uint32_t i = 0, e = sbProcess.GetNumThreads(); i < e; ++i) {
+ const lldb::SBThread thread = sbProcess.GetThreadAtIndex(i);
+ if (!thread.IsValid())
+continue;
+ thread.GetDescription(streamOut);
+}
+bOk = TextToStdout(streamOut.GetData());
} else {
-lldb::SBStream streamOut;
const MIuint nTargetIndex = rDebugger.GetIndexOfTarget(target);
if (nTargetIndex != UINT_MAX)
streamOut.Printf("Target %d: (", nTargetIndex);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49779: Make framework-header-fix process copied headers
keith added inline comments.
Comment at: cmake/modules/LLDBFramework.cmake:41
+add_custom_target(lldb-framework-headers
+ DEPENDS ${framework_headers}
+ COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
xiaobai wrote:
> keith wrote:
> > xiaobai wrote:
> > > This should not just depend on `framework_headers`, because those are in
> > > the location `${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders`. You want to
> > > run the script on `$/Headers`, which is not
> > > guaranteed to exist or have been populated with headers when this
> > > actually gets run. See my comment above.
> > Updated this by making it a POST_BUILD command instead
> Can you combine this with the lldb-framework POST_BUILD above? After that
> this should be good to go.
If I combine it with the one above I'd have to do it twice I think?
https://reviews.llvm.org/D49779
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49779: Make framework-header-fix process copied headers
xiaobai added inline comments.
Comment at: cmake/modules/LLDBFramework.cmake:41
+add_custom_target(lldb-framework-headers
+ DEPENDS ${framework_headers}
+ COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
keith wrote:
> xiaobai wrote:
> > keith wrote:
> > > xiaobai wrote:
> > > > This should not just depend on `framework_headers`, because those are
> > > > in the location `${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders`. You
> > > > want to run the script on `$/Headers`, which
> > > > is not guaranteed to exist or have been populated with headers when
> > > > this actually gets run. See my comment above.
> > > Updated this by making it a POST_BUILD command instead
> > Can you combine this with the lldb-framework POST_BUILD above? After that
> > this should be good to go.
> If I combine it with the one above I'd have to do it twice I think?
I think if you insert the command after moving the headers then you shouldn't
have to do it twice
https://reviews.llvm.org/D49779
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49779: Make framework-header-fix process copied headers
keith added inline comments.
Comment at: cmake/modules/LLDBFramework.cmake:41
+add_custom_target(lldb-framework-headers
+ DEPENDS ${framework_headers}
+ COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
xiaobai wrote:
> keith wrote:
> > xiaobai wrote:
> > > keith wrote:
> > > > xiaobai wrote:
> > > > > This should not just depend on `framework_headers`, because those are
> > > > > in the location `${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders`. You
> > > > > want to run the script on `$/Headers`, which
> > > > > is not guaranteed to exist or have been populated with headers when
> > > > > this actually gets run. See my comment above.
> > > > Updated this by making it a POST_BUILD command instead
> > > Can you combine this with the lldb-framework POST_BUILD above? After that
> > > this should be good to go.
> > If I combine it with the one above I'd have to do it twice I think?
> I think if you insert the command after moving the headers then you shouldn't
> have to do it twice
I might be misunderstanding the suggestion. I think I would have to after line
21 and line 28
https://reviews.llvm.org/D49779
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49779: Make framework-header-fix process copied headers
xiaobai added inline comments.
Comment at: cmake/modules/LLDBFramework.cmake:41
+add_custom_target(lldb-framework-headers
+ DEPENDS ${framework_headers}
+ COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
keith wrote:
> xiaobai wrote:
> > keith wrote:
> > > xiaobai wrote:
> > > > keith wrote:
> > > > > xiaobai wrote:
> > > > > > This should not just depend on `framework_headers`, because those
> > > > > > are in the location `${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders`.
> > > > > > You want to run the script on `$/Headers`,
> > > > > > which is not guaranteed to exist or have been populated with
> > > > > > headers when this actually gets run. See my comment above.
> > > > > Updated this by making it a POST_BUILD command instead
> > > > Can you combine this with the lldb-framework POST_BUILD above? After
> > > > that this should be good to go.
> > > If I combine it with the one above I'd have to do it twice I think?
> > I think if you insert the command after moving the headers then you
> > shouldn't have to do it twice
> I might be misunderstanding the suggestion. I think I would have to after
> line 21 and line 28
Oh, completely forgot about the line 28 case. In that case, why not pull out
the copying of headers to right above this one then? Should allow us to prevent
duplicating that logic.
https://reviews.llvm.org/D49779
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49779: Make framework-header-fix process copied headers
keith added inline comments.
Comment at: cmake/modules/LLDBFramework.cmake:41
+add_custom_target(lldb-framework-headers
+ DEPENDS ${framework_headers}
+ COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
xiaobai wrote:
> keith wrote:
> > xiaobai wrote:
> > > keith wrote:
> > > > xiaobai wrote:
> > > > > keith wrote:
> > > > > > xiaobai wrote:
> > > > > > > This should not just depend on `framework_headers`, because those
> > > > > > > are in the location
> > > > > > > `${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders`. You want to run
> > > > > > > the script on `$/Headers`, which is not
> > > > > > > guaranteed to exist or have been populated with headers when this
> > > > > > > actually gets run. See my comment above.
> > > > > > Updated this by making it a POST_BUILD command instead
> > > > > Can you combine this with the lldb-framework POST_BUILD above? After
> > > > > that this should be good to go.
> > > > If I combine it with the one above I'd have to do it twice I think?
> > > I think if you insert the command after moving the headers then you
> > > shouldn't have to do it twice
> > I might be misunderstanding the suggestion. I think I would have to after
> > line 21 and line 28
> Oh, completely forgot about the line 28 case. In that case, why not pull out
> the copying of headers to right above this one then? Should allow us to
> prevent duplicating that logic.
Done!
https://reviews.llvm.org/D49779
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49779: Make framework-header-fix process copied headers
keith updated this revision to Diff 157547.
keith added a comment.
- Hoist LLDB.framework headers copy out of condition
https://reviews.llvm.org/D49779
Files:
cmake/modules/LLDBFramework.cmake
Index: cmake/modules/LLDBFramework.cmake
===
--- cmake/modules/LLDBFramework.cmake
+++ cmake/modules/LLDBFramework.cmake
@@ -12,24 +12,21 @@
COMMAND ${CMAKE_COMMAND} -E copy ${header}
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
list(APPEND framework_headers
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
endforeach()
-add_custom_target(lldb-framework-headers
- DEPENDS ${framework_headers}
- COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
${CMAKE_CURRENT_BINARY_DIR} ${LLDB_VERSION})
+
+add_custom_command(TARGET lldb-framework POST_BUILD
+ COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
+ COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
$/Headers ${LLDB_VERSION}
+)
if (NOT IOS)
if (NOT LLDB_BUILT_STANDALONE)
add_dependencies(lldb-framework clang-headers)
endif()
add_custom_command(TARGET lldb-framework POST_BUILD
-COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
COMMAND ${CMAKE_COMMAND} -E create_symlink Versions/Current/Headers
${LLDB_FRAMEWORK_DIR}/LLDB.framework/Headers
COMMAND ${CMAKE_COMMAND} -E create_symlink ${LLDB_FRAMEWORK_VERSION}
${LLDB_FRAMEWORK_DIR}/LLDB.framework/Versions/Current
COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/clang/${LLDB_VERSION}
$/Resources/Clang
)
-else()
- add_custom_command(TARGET lldb-framework POST_BUILD
-COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
- )
endif()
set_target_properties(liblldb PROPERTIES
@@ -41,5 +38,4 @@
PUBLIC_HEADER "${framework_headers}")
add_dependencies(lldb-framework
- lldb-framework-headers
lldb-suite)
Index: cmake/modules/LLDBFramework.cmake
===
--- cmake/modules/LLDBFramework.cmake
+++ cmake/modules/LLDBFramework.cmake
@@ -12,24 +12,21 @@
COMMAND ${CMAKE_COMMAND} -E copy ${header} ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
list(APPEND framework_headers ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
endforeach()
-add_custom_target(lldb-framework-headers
- DEPENDS ${framework_headers}
- COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh ${CMAKE_CURRENT_BINARY_DIR} ${LLDB_VERSION})
+
+add_custom_command(TARGET lldb-framework POST_BUILD
+ COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
+ COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh $/Headers ${LLDB_VERSION}
+)
if (NOT IOS)
if (NOT LLDB_BUILT_STANDALONE)
add_dependencies(lldb-framework clang-headers)
endif()
add_custom_command(TARGET lldb-framework POST_BUILD
-COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
COMMAND ${CMAKE_COMMAND} -E create_symlink Versions/Current/Headers ${LLDB_FRAMEWORK_DIR}/LLDB.framework/Headers
COMMAND ${CMAKE_COMMAND} -E create_symlink ${LLDB_FRAMEWORK_VERSION} ${LLDB_FRAMEWORK_DIR}/LLDB.framework/Versions/Current
COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/clang/${LLDB_VERSION} $/Resources/Clang
)
-else()
- add_custom_command(TARGET lldb-framework POST_BUILD
-COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
- )
endif()
set_target_properties(liblldb PROPERTIES
@@ -41,5 +38,4 @@
PUBLIC_HEADER "${framework_headers}")
add_dependencies(lldb-framework
- lldb-framework-headers
lldb-suite)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49779: Make framework-header-fix process copied headers
xiaobai accepted this revision. xiaobai added a comment. This revision is now accepted and ready to land. Awesome! Thank you so much for your patience and contribution. :) Do you need somebody to commit this for you? https://reviews.llvm.org/D49779 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49779: Make framework-header-fix process copied headers
keith added a comment. No problem! Yes please! :) https://reviews.llvm.org/D49779 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49779: Make framework-header-fix process copied headers
This revision was automatically updated to reflect the committed changes.
Closed by commit rL338058: Make framework-header-fix process copied headers
(authored by xiaobai, committed by ).
Herald added a subscriber: llvm-commits.
Repository:
rL LLVM
https://reviews.llvm.org/D49779
Files:
lldb/trunk/cmake/modules/LLDBFramework.cmake
Index: lldb/trunk/cmake/modules/LLDBFramework.cmake
===
--- lldb/trunk/cmake/modules/LLDBFramework.cmake
+++ lldb/trunk/cmake/modules/LLDBFramework.cmake
@@ -12,24 +12,21 @@
COMMAND ${CMAKE_COMMAND} -E copy ${header}
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
list(APPEND framework_headers
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
endforeach()
-add_custom_target(lldb-framework-headers
- DEPENDS ${framework_headers}
- COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
${CMAKE_CURRENT_BINARY_DIR} ${LLDB_VERSION})
+
+add_custom_command(TARGET lldb-framework POST_BUILD
+ COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
+ COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
$/Headers ${LLDB_VERSION}
+)
if (NOT IOS)
if (NOT LLDB_BUILT_STANDALONE)
add_dependencies(lldb-framework clang-headers)
endif()
add_custom_command(TARGET lldb-framework POST_BUILD
-COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
COMMAND ${CMAKE_COMMAND} -E create_symlink Versions/Current/Headers
${LLDB_FRAMEWORK_DIR}/LLDB.framework/Headers
COMMAND ${CMAKE_COMMAND} -E create_symlink ${LLDB_FRAMEWORK_VERSION}
${LLDB_FRAMEWORK_DIR}/LLDB.framework/Versions/Current
COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/clang/${LLDB_VERSION}
$/Resources/Clang
)
-else()
- add_custom_command(TARGET lldb-framework POST_BUILD
-COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
- )
endif()
set_target_properties(liblldb PROPERTIES
@@ -41,5 +38,4 @@
PUBLIC_HEADER "${framework_headers}")
add_dependencies(lldb-framework
- lldb-framework-headers
lldb-suite)
Index: lldb/trunk/cmake/modules/LLDBFramework.cmake
===
--- lldb/trunk/cmake/modules/LLDBFramework.cmake
+++ lldb/trunk/cmake/modules/LLDBFramework.cmake
@@ -12,24 +12,21 @@
COMMAND ${CMAKE_COMMAND} -E copy ${header} ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
list(APPEND framework_headers ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
endforeach()
-add_custom_target(lldb-framework-headers
- DEPENDS ${framework_headers}
- COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh ${CMAKE_CURRENT_BINARY_DIR} ${LLDB_VERSION})
+
+add_custom_command(TARGET lldb-framework POST_BUILD
+ COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
+ COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh $/Headers ${LLDB_VERSION}
+)
if (NOT IOS)
if (NOT LLDB_BUILT_STANDALONE)
add_dependencies(lldb-framework clang-headers)
endif()
add_custom_command(TARGET lldb-framework POST_BUILD
-COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
COMMAND ${CMAKE_COMMAND} -E create_symlink Versions/Current/Headers ${LLDB_FRAMEWORK_DIR}/LLDB.framework/Headers
COMMAND ${CMAKE_COMMAND} -E create_symlink ${LLDB_FRAMEWORK_VERSION} ${LLDB_FRAMEWORK_DIR}/LLDB.framework/Versions/Current
COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/clang/${LLDB_VERSION} $/Resources/Clang
)
-else()
- add_custom_command(TARGET lldb-framework POST_BUILD
-COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
- )
endif()
set_target_properties(liblldb PROPERTIES
@@ -41,5 +38,4 @@
PUBLIC_HEADER "${framework_headers}")
add_dependencies(lldb-framework
- lldb-framework-headers
lldb-suite)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r338058 - Make framework-header-fix process copied headers
Author: xiaobai
Date: Thu Jul 26 12:04:46 2018
New Revision: 338058
URL: http://llvm.org/viewvc/llvm-project?rev=338058&view=rev
Log:
Make framework-header-fix process copied headers
Summary:
Previously the framework-header-fix script would change the sources
before they were copied, leading to unnecessary rebuilds on repeat
`ninja lldb` invocations. This runs the script on the headers after
they're copied into the produced LLDB.framework, meaning it doesn't
affect any files being built.
Patch by Keith Smiley !
Differential Revision: https://reviews.llvm.org/D49779
Modified:
lldb/trunk/cmake/modules/LLDBFramework.cmake
Modified: lldb/trunk/cmake/modules/LLDBFramework.cmake
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBFramework.cmake?rev=338058&r1=338057&r2=338058&view=diff
==
--- lldb/trunk/cmake/modules/LLDBFramework.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBFramework.cmake Thu Jul 26 12:04:46 2018
@@ -12,24 +12,21 @@ foreach(header
COMMAND ${CMAKE_COMMAND} -E copy ${header}
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
list(APPEND framework_headers
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
endforeach()
-add_custom_target(lldb-framework-headers
- DEPENDS ${framework_headers}
- COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
${CMAKE_CURRENT_BINARY_DIR} ${LLDB_VERSION})
+
+add_custom_command(TARGET lldb-framework POST_BUILD
+ COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
+ COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
$/Headers ${LLDB_VERSION}
+)
if (NOT IOS)
if (NOT LLDB_BUILT_STANDALONE)
add_dependencies(lldb-framework clang-headers)
endif()
add_custom_command(TARGET lldb-framework POST_BUILD
-COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
COMMAND ${CMAKE_COMMAND} -E create_symlink Versions/Current/Headers
${LLDB_FRAMEWORK_DIR}/LLDB.framework/Headers
COMMAND ${CMAKE_COMMAND} -E create_symlink ${LLDB_FRAMEWORK_VERSION}
${LLDB_FRAMEWORK_DIR}/LLDB.framework/Versions/Current
COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/clang/${LLDB_VERSION}
$/Resources/Clang
)
-else()
- add_custom_command(TARGET lldb-framework POST_BUILD
-COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
- )
endif()
set_target_properties(liblldb PROPERTIES
@@ -41,5 +38,4 @@ set_target_properties(liblldb PROPERTIES
PUBLIC_HEADER "${framework_headers}")
add_dependencies(lldb-framework
- lldb-framework-headers
lldb-suite)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r338074 - Add back lldb-framework-headers target
Author: xiaobai
Date: Thu Jul 26 14:55:14 2018
New Revision: 338074
URL: http://llvm.org/viewvc/llvm-project?rev=338074&view=rev
Log:
Add back lldb-framework-headers target
In r338058 we removed the target `lldb-framework-headers`, which mean
lldb-framework no longer depended on `framework_headers`, so they never
actually got generated. This is a partial revert of r338058: I added
back the lldb-framework-headers target, but the framework-header-fix.sh
script still runs on the copied headers.
Modified:
lldb/trunk/cmake/modules/LLDBFramework.cmake
Modified: lldb/trunk/cmake/modules/LLDBFramework.cmake
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBFramework.cmake?rev=338074&r1=338073&r2=338074&view=diff
==
--- lldb/trunk/cmake/modules/LLDBFramework.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBFramework.cmake Thu Jul 26 14:55:14 2018
@@ -13,6 +13,8 @@ foreach(header
list(APPEND framework_headers
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders/${basename})
endforeach()
+add_custom_target(lldb-framework-headers DEPENDS ${framework_headers})
+
add_custom_command(TARGET lldb-framework POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_directory
${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh
$/Headers ${LLDB_VERSION}
@@ -38,4 +40,5 @@ set_target_properties(liblldb PROPERTIES
PUBLIC_HEADER "${framework_headers}")
add_dependencies(lldb-framework
+ lldb-framework-headers
lldb-suite)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49888: Stop building liblldb with CMake's framework functionality
xiaobai created this revision.
xiaobai added a reviewer: labath.
Herald added a subscriber: mgorny.
CMake has a bug in its ninja generator that prevents you from
installing targets that are built with framework support. Therefore, I want to
not rely on CMake's framework support.
https://reviews.llvm.org/D49888
Files:
CMakeLists.txt
cmake/modules/AddLLDB.cmake
cmake/modules/LLDBConfig.cmake
cmake/modules/LLDBFramework.cmake
scripts/CMakeLists.txt
source/API/CMakeLists.txt
Index: source/API/CMakeLists.txt
===
--- source/API/CMakeLists.txt
+++ source/API/CMakeLists.txt
@@ -110,10 +110,20 @@
PROPERTY COMPILE_FLAGS " -Wno-sequence-point -Wno-cast-qual")
endif ()
-set_target_properties(liblldb
- PROPERTIES
- VERSION ${LLDB_VERSION}
-)
+if (LLDB_BUILD_FRAMEWORK)
+ set_target_properties(liblldb
+PROPERTIES
+LIBRARY_OUTPUT_DIRECTORY ${LLDB_FRAMEWORK_DIR}/Versions/${LLDB_FRAMEWORK_VERSION}
+PREFIX ""
+SUFFIX ""
+INSTALL_NAME_DIR "@rpath/LLDB.framework"
+OUTPUT_NAME LLDB)
+else()
+ set_target_properties(liblldb
+PROPERTIES
+VERSION ${LLDB_VERSION}
+OUTPUT_NAME lldb)
+endif()
if (NOT CMAKE_SYSTEM_NAME MATCHES "Windows")
if (NOT LLDB_EXPORT_ALL_SYMBOLS)
@@ -136,11 +146,6 @@
if (MSVC AND NOT LLDB_DISABLE_PYTHON)
target_link_libraries(liblldb PRIVATE ${PYTHON_LIBRARY})
endif()
-else()
- set_target_properties(liblldb
-PROPERTIES
-OUTPUT_NAME lldb
- )
endif()
if (LLDB_WRAP_PYTHON)
Index: scripts/CMakeLists.txt
===
--- scripts/CMakeLists.txt
+++ scripts/CMakeLists.txt
@@ -25,9 +25,9 @@
if(LLDB_BUILD_FRAMEWORK)
set(framework_arg --framework --target-platform Darwin)
set(SWIG_PYTHON_DIR
-${LLDB_PYTHON_TARGET_DIR}/${LLDB_FRAMEWORK_RESOURCE_DIR}/Python)
+${LLDB_FRAMEWORK_DIR}/${LLDB_FRAMEWORK_RESOURCE_DIR}/Python)
set(SWIG_INSTALL_DIR
-${LLDB_FRAMEWORK_INSTALL_DIR}/${LLDB_FRAMEWORK_RESOURCE_DIR})
+${LLDB_FRAMEWORK_INSTALL_DIR}/LLDB.framework/${LLDB_FRAMEWORK_RESOURCE_DIR})
endif()
get_filename_component(CFGBLDDIR ${LLDB_WRAP_PYTHON} DIRECTORY)
@@ -52,7 +52,7 @@
COMMENT "Python script building LLDB Python wrapper")
add_custom_target(swig_wrapper ALL DEPENDS ${LLDB_WRAP_PYTHON})
-set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/lldb.py PROPERTIES GENERATED 1)
+set_source_files_properties(${LLDB_PYTHON_TARGET_DIR}/lldb.py PROPERTIES GENERATED 1)
# Install the LLDB python module
Index: cmake/modules/LLDBFramework.cmake
===
--- cmake/modules/LLDBFramework.cmake
+++ cmake/modules/LLDBFramework.cmake
@@ -1,3 +1,13 @@
+# We set up part of the framework structure first, as some scripts and build
+# rules assume they exist already.
+file(MAKE_DIRECTORY ${LLDB_FRAMEWORK_DIR} ${LLDB_FRAMEWORK_DIR}/${LLDB_FRAMEWORK_RESOURCE_DIR})
+execute_process(
+ COMMAND
+${CMAKE_COMMAND} -E create_symlink ${LLDB_FRAMEWORK_VERSION} ${LLDB_FRAMEWORK_DIR}/Versions/Current
+ COMMAND
+${CMAKE_COMMAND} -E create_symlink Versions/Current/Resources ${LLDB_FRAMEWORK_DIR}/Resources
+)
+
file(GLOB public_headers ${LLDB_SOURCE_DIR}/include/lldb/API/*.h)
file(GLOB root_public_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-*.h)
file(GLOB root_private_headers ${LLDB_SOURCE_DIR}/include/lldb/lldb-private*.h)
@@ -16,28 +26,29 @@
add_custom_target(lldb-framework-headers DEPENDS ${framework_headers})
add_custom_command(TARGET lldb-framework POST_BUILD
- COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders $/Headers
- COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh $/Headers ${LLDB_VERSION}
+ COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_BINARY_DIR}/FrameworkHeaders ${LLDB_FRAMEWORK_DIR}/${LLDB_FRAMEWORK_HEADER_DIR}
+ COMMAND ${LLDB_SOURCE_DIR}/scripts/framework-header-fix.sh ${LLDB_FRAMEWORK_DIR}/${LLDB_FRAMEWORK_HEADER_DIR} ${LLDB_VERSION}
)
if (NOT IOS)
if (NOT LLDB_BUILT_STANDALONE)
add_dependencies(lldb-framework clang-headers)
endif()
add_custom_command(TARGET lldb-framework POST_BUILD
-COMMAND ${CMAKE_COMMAND} -E create_symlink Versions/Current/Headers ${LLDB_FRAMEWORK_DIR}/LLDB.framework/Headers
-COMMAND ${CMAKE_COMMAND} -E create_symlink ${LLDB_FRAMEWORK_VERSION} ${LLDB_FRAMEWORK_DIR}/LLDB.framework/Versions/Current
-COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/clang/${LLDB_VERSION} $/Resources/Clang
+COMMAND ${CMAKE_COMMAND} -E create_symlink Versions/Current/Headers ${LLDB_FRAMEWORK_DIR}/Headers
+COMMAND ${CMAKE_COMMAND} -E create_symlink Versions/Current/LLDB ${LLDB_FRAMEWORK_DIR}/LLDB
+COMMAND ${CMAKE_COMMAND} -E create_symlink ${LLDB_FRAMEWORK_VERSION} ${LLDB_FRAMEWORK_DIR}/Versions/Current
+COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_BINARY_DIR}/lib${LLVM_L
[Lldb-commits] [PATCH] D49888: Stop building liblldb with CMake's framework functionality
xiaobai added a comment. Tested this by invoking cmake .. -G Ninja -DCMAKE_BUILD_TYPE=Debug -DLLDB_BUILD_FRAMEWORK=1 && ninja lldb The resulting framework appears to be the same as before. https://reviews.llvm.org/D49888 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49410: [PDB] Parse UDT symbols and pointers to members
zturner accepted this revision. zturner added a comment. This revision is now accepted and ready to land. I am not sure what are the drawbacks of such a solution are. I guess the best way to find out is to try it and see if you observe any strange behavior :) I'm ok with that, for now. https://reviews.llvm.org/D49410 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49410: [PDB] Parse UDT symbols and pointers to members
aleksandr.urakov added a comment. Thanks! I have created the corresponding patch for Clang (https://reviews.llvm.org/D49871, @rnk have accepted it. Can you commit this, please? I have no commit access). But current patch intersects with https://reviews.llvm.org/D49368, and I'm preparing the combined patch (we were talking about it some earlier in the thread), so can you, please, NOT commit current patch now? :) I'll submit the combined patch on Monday (I have a day off today), it's almost ready. https://reviews.llvm.org/D49410 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D49410: [PDB] Parse UDT symbols and pointers to members
In the meantime, perhaps you could request commit access :) On Thu, Jul 26, 2018 at 9:30 PM Aleksandr Urakov via Phabricator < revi...@reviews.llvm.org> wrote: > aleksandr.urakov added a comment. > > Thanks! > > I have created the corresponding patch for Clang ( > https://reviews.llvm.org/D49871, @rnk have accepted it. Can you commit > this, please? I have no commit access). > > But current patch intersects with https://reviews.llvm.org/D49368, and > I'm preparing the combined patch (we were talking about it some earlier in > the thread), so can you, please, NOT commit current patch now? :) I'll > submit the combined patch on Monday (I have a day off today), it's almost > ready. > > > https://reviews.llvm.org/D49410 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49410: [PDB] Parse UDT symbols and pointers to members
zturner added a comment. In the meantime, perhaps you could request commit access :) https://reviews.llvm.org/D49410 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D49410: [PDB] Parse UDT symbols and pointers to members
aleksandr.urakov added a comment. It would be great, thank you! I'll also do it on Monday, if it's already possible. https://reviews.llvm.org/D49410 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
