date:20201027

[Lldb-commits] [PATCH] D90102: [lldb] [Process/FreeBSDRemote] Enable watchpoint support

2020-10-27 Thread Pavel Labath via Phabricator via lldb-commits

labath accepted this revision.
labath added inline comments.
This revision is now accepted and ready to land.



Comment at: 
lldb/source/Plugins/Process/FreeBSDRemote/NativeThreadFreeBSD.cpp:192-193
+return Status("not implemented");
+  if (m_state == eStateLaunching)
+return Status();
+  Status error = RemoveWatchpoint(addr);

Are you actually using this state for anything? Should this be an assert? Maybe 
`assert(m_state == eStateStopped)` even ?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90102/new/

https://reviews.llvm.org/D90102

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D90102: [lldb] [Process/FreeBSDRemote] Enable watchpoint support

2020-10-27 Thread Michał Górny via Phabricator via lldb-commits

mgorny added inline comments.



Comment at: 
lldb/source/Plugins/Process/FreeBSDRemote/NativeThreadFreeBSD.cpp:192-193
+return Status("not implemented");
+  if (m_state == eStateLaunching)
+return Status();
+  Status error = RemoveWatchpoint(addr);

labath wrote:
> Are you actually using this state for anything? Should this be an assert? 
> Maybe `assert(m_state == eStateStopped)` even ?
I don't know, I am a copy-paste monkey ;-). I've presumed LLDB core controls in 
which states the method will be called.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90102/new/

https://reviews.llvm.org/D90102

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D87172: Check if debug line sequences are starting after the first code segment

2020-10-27 Thread Pavel Labath via Phabricator via lldb-commits

labath accepted this revision.
labath added inline comments.



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:503-505
+  if (section_list) {
+InitializeFirstCodeAddress(*section_list);
+  }

clayborg wrote:
> remove braces
or even fold the declaration into the if condition.



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h:520
   std::vector m_lldb_cu_to_dwarf_unit;
+  lldb::addr_t m_first_code_address = LLDB_INVALID_ADDRESS;
 };

aadsm wrote:
> labath wrote:
> > clayborg wrote:
> > > A lengthy comment would be great here. Maybe something like:
> > > 
> > > ```
> > > /// Many linkers will concatenate all available DWARF, even if parts of 
> > > that DWARF
> > > /// should have been dead stripped. Some linkers will place tombstone 
> > > values in for
> > > /// addresses that should have been dead stripped, with a value like -1 
> > > or -2. But many
> > > /// linkers will apply a relocation and attempt to set the value to zero. 
> > > This is problematic
> > > /// in that we can end up with many addresses that are zero or close to 
> > > zero due to there
> > > /// being an addend on the relocation whose base is at zero. Here we 
> > > attempt to avoid 
> > > /// addresses that are zero or close to zero by finding the first valid 
> > > code address by looking
> > > /// at the sections and finding the first one that has read + execute 
> > > permissions. This allows
> > > /// us to do a quick and cheap comparison against this address when 
> > > parsing line tables and
> > > /// parsing functions where the DWARF should have been dead stripped.
> > > ```
> > To me, "should have been stripped" implies that the linkers are doing 
> > something wrong, as if they were required to parse and rewrite the dwarf in 
> > the input files. However, there is nothing in the DWARF or ELF specs that 
> > would support that, and the linkers are simply doing what the specs say, 
> > and what linkers have been doing since the dawn of time -- concatenate 
> > things.
> > 
> > It would be better to just state the facts here, instead of passing 
> > judgement (or make an appearance of doing that).
> @clayborg can you clarify this comment like @labath suggests?
How about this:
```
DWARF does not provide a good way for traditional (concatenating) linkers to 
invalidate debug info describing dead-stripped code. These linkers will keep 
the debug info but resolve any addresses referring to such code as zero (BFD), 
a small positive integer (zero + relocation addend -- GOLD), or -1/-2 (LLD). 
Try to filter out this debug info by comparing it to the lowest code address in 
the module.
```



Comment at: 
lldb/test/Shell/SymbolFile/DWARF/line-entries-invalid-addresses.yaml:3
+# RUN: %lldb %t -b -o "image lookup -f main.cpp -l 2 -v" | FileCheck %s
+# CHECK: LineEntry: {{.*}}main.cpp:2:{{.*}}
+

aadsm wrote:
> labath wrote:
> > I think you also need to check for the "1 matches found", otherwise this 
> > will succeed even without the patch.
> This should be fine, this is what you get without the patch:
> 
> ```
> (lldb) image lookup -f main.cpp -l 2 -v
> 1 match found in main.cpp:2 in /Users/aadsm/Projects/test-bad.obj:
> Address:  ()
> Summary:
> ```
True, but adding the check still wouldn't hurt, as one can imagine a bug that 
would cause the second main.cpp:2 entry (at address 0xf) to make its way here 
-- and that's what we're trying to avoid.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87172/new/

https://reviews.llvm.org/D87172

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D90102: [lldb] [Process/FreeBSDRemote] Enable watchpoint support

2020-10-27 Thread Pavel Labath via Phabricator via lldb-commits

labath added inline comments.

Comment at: 
lldb/source/Plugins/Process/FreeBSDRemote/NativeThreadFreeBSD.cpp:192-193
+return Status("not implemented");
+  if (m_state == eStateLaunching)
+return Status();
+  Status error = RemoveWatchpoint(addr);

mgorny wrote:
> labath wrote:
> > Are you actually using this state for anything? Should this be an assert? 
> > Maybe `assert(m_state == eStateStopped)` even ?
> I don't know, I am a copy-paste monkey ;-). I've presumed LLDB core controls 
> in which states the method will be called.
Did you copy this code from the in-process plugin? That one uses more states 
(including this one), and I am not sure about the kind of controls it has.

lldb-server is much simpler, and and I'm confident that it won't call any of 
these functions when the process is not stopped (but asserting that doesn't 
hurt).. It also doesn't use eStateLaunching at all (unless you've added it 
somewhere in the freebsd code, but I hadn't noticed anything). This last bit is 
also the reason why I'd like to use a different State enum in lldb-server one 
day...

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90102/new/

https://reviews.llvm.org/D90102

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 1f933ff - [lldb][NFC] Rewrite TestQuoting

2020-10-27 Thread Raphael Isemann via lldb-commits


Author: Raphael Isemann
Date: 2020-10-27T11:12:17+01:00
New Revision: 1f933ff999f2c0373c79ddf23539873cbfa923e5

URL: 
https://github.com/llvm/llvm-project/commit/1f933ff999f2c0373c79ddf23539873cbfa923e5
DIFF: 
https://github.com/llvm/llvm-project/commit/1f933ff999f2c0373c79ddf23539873cbfa923e5.diff

LOG: [lldb][NFC] Rewrite TestQuoting

TestQuoting's different test methods all build their own test binaries but
we can just reuse the same test binary by merging all asserts into one method.
This reduces the test runtime from 8 seconds to 4 seconds on my machine.
This also removes the ability to have partial failures in this test, but given
how rarely this code is touched this seems like a fair tradeoff (and we will be
able to re-add this feature once we updated our test framework).

Some other small changes:
  * Fixed that we cleanup "stdout.txt" instead of "output.txt" in the cleanup.
  * Fixed some formatting issues.
  * Call `build` instead of directly calling `buildDefault`.

Added: 


Modified: 
lldb/test/API/commands/settings/quoting/TestQuoting.py

Removed: 




diff  --git a/lldb/test/API/commands/settings/quoting/TestQuoting.py 
b/lldb/test/API/commands/settings/quoting/TestQuoting.py
index a415ea8ee247..a64c34a6ff38 100644
--- a/lldb/test/API/commands/settings/quoting/TestQuoting.py
+++ b/lldb/test/API/commands/settings/quoting/TestQuoting.py
@@ -1,10 +1,7 @@
 """
-Test quoting of arguments to lldb commands
+Test quoting of arguments to lldb commands.
 """
 
-
-
-
 import lldb
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
@@ -14,81 +11,62 @@
 class SettingsCommandTestCase(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
+output_file_name = "output.txt"
 
 @classmethod
 def classCleanup(cls):
 """Cleanup the test byproducts."""
-cls.RemoveTempFile("stdout.txt")
-
-@no_debug_info_test
-def test_no_quote(self):
-self.do_test_args("a b c", "a\0b\0c\0")
-
-@no_debug_info_test
-def test_single_quote(self):
-self.do_test_args("'a b c'", "a b c\0")
+cls.RemoveTempFile(SettingsCommandTestCase.output_file_name)
 
+@skipIfReproducer  # Reproducers don't know about output.txt
 @no_debug_info_test
-def test_double_quote(self):
-self.do_test_args('"a b c"', "a b c\0")
-
-@no_debug_info_test
-def test_single_quote_escape(self):
-self.do_test_args("'a b\\' c", "a b\\\0c\0")
-
-@no_debug_info_test
-def test_double_quote_escape(self):
-self.do_test_args('"a b\\" c"', 'a b" c\0')
-
-@no_debug_info_test
-def test_double_quote_escape2(self):
-self.do_test_args('"a b" c', 'a b\\\0c\0')
-
-@no_debug_info_test
-def test_single_in_double(self):
-self.do_test_args('"a\'b"', "a'b\0")
-
-@no_debug_info_test
-def test_double_in_single(self):
-self.do_test_args("'a\"b'", 'a"b\0')
-
-@no_debug_info_test
-def test_combined(self):
-self.do_test_args('"a b"c\'d e\'', 'a bcd e\0')
-
-@no_debug_info_test
-def test_bare_single(self):
-self.do_test_args("a\\'b", "a'b\0")
-
-@no_debug_info_test
-def test_bare_double(self):
-self.do_test_args('a\\"b', 'a"b\0')
+def test(self):
+self.build()
+exe = self.getBuildArtifact("a.out")
+self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
 
-@skipIfReproducer # Reproducers don't know about output.txt
-def do_test_args(self, args_in, args_out):
+# No quotes.
+self.expect_args("a b c", "a\0b\0c\0")
+# Single quotes.
+self.expect_args("'a b c'", "a b c\0")
+# Double quotes.
+self.expect_args('"a b c"', "a b c\0")
+# Single quote escape.
+self.expect_args("'a b\\' c", "a b\\\0c\0")
+# Double quote escape.
+self.expect_args('"a b\\" c"', 'a b" c\0')
+self.expect_args('"a b" c', 'a b\\\0c\0')
+# Single quote in double quotes.
+self.expect_args('"a\'b"', "a'b\0")
+# Double quotes in single quote.
+self.expect_args("'a\"b'", 'a"b\0')
+# Combined quotes.
+self.expect_args('"a b"c\'d e\'', 'a bcd e\0')
+# Bare single/double quotes.
+self.expect_args("a\\'b", "a'b\0")
+self.expect_args('a\\"b', 'a"b\0')
+
+def expect_args(self, args_in, args_out):
 """Test argument parsing. Run the program with args_in. The program 
dumps its arguments
 to stdout. Compare the stdout with args_out."""
-self.buildDefault()
 
-exe = self.getBuildArtifact("a.out")
-self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
+filename = SettingsCommandTestCase.output_file_name
 
-local_outfile = self.getBuildArtifact("output.txt")
 if lldb.remote_platform:
-remote_outfile = lldb.remote_platform.GetWorkingDirectory(

[Lldb-commits] [PATCH] D89334: [lldb] Support Python imports relative the to the current file being sourced

2020-10-27 Thread Pavel Labath via Phabricator via lldb-commits

labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Let's see how this goes.




Comment at: lldb/source/Commands/Options.td:709
+Group<1>, Desc<"Resolve relative paths relative to the location of the "
+"current command file being sourced. This argument is ignored when not "
+"coming form a command file.">;

It might be better to make this an error



Comment at: 
lldb/test/Shell/ScriptInterpreter/Python/command_relative_import.test:4-9
+# RUN: cp %S/Inputs/magritte.py %t/foo
+# RUN: cp %S/Inputs/magritte.in %t/foo
+# RUN: cp %S/Inputs/zip.py %t/foo
+# RUN: cp %S/Inputs/zip.in %t/foo
+# RUN: cp %S/Inputs/hello.py %t/foo/bar/baz
+# RUN: cp %S/Inputs/hello.in %t/foo/bar

consider using the (new) split-file utility -- It can split single file into 
multiple chunks and place them in the appropriate folders.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89334/new/

https://reviews.llvm.org/D89334

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D90102: [lldb] [Process/FreeBSDRemote] Enable watchpoint support

2020-10-27 Thread Michał Górny via Phabricator via lldb-commits

mgorny added inline comments.



Comment at: 
lldb/source/Plugins/Process/FreeBSDRemote/NativeThreadFreeBSD.cpp:192-193
+return Status("not implemented");
+  if (m_state == eStateLaunching)
+return Status();
+  Status error = RemoveWatchpoint(addr);

labath wrote:
> mgorny wrote:
> > labath wrote:
> > > Are you actually using this state for anything? Should this be an assert? 
> > > Maybe `assert(m_state == eStateStopped)` even ?
> > I don't know, I am a copy-paste monkey ;-). I've presumed LLDB core 
> > controls in which states the method will be called.
> Did you copy this code from the in-process plugin? That one uses more states 
> (including this one), and I am not sure about the kind of controls it has.
> 
> lldb-server is much simpler, and and I'm confident that it won't call any of 
> these functions when the process is not stopped (but asserting that doesn't 
> hurt).. It also doesn't use eStateLaunching at all (unless you've added it 
> somewhere in the freebsd code, but I hadn't noticed anything). This last bit 
> is also the reason why I'd like to use a different State enum in lldb-server 
> one day...
No, I've copied it from NetBSD. I suppose I'll end up backporting a lot of 
fixes to NetBSD plugin ;-).

So generally assert that it's stopped. Ok.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90102/new/

https://reviews.llvm.org/D90102

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] f8a3b9b - [lldb] Correct vFile:pread/pwrite packet docs

2020-10-27 Thread David Spickett via lldb-commits


Author: David Spickett
Date: 2020-10-27T11:47:35Z
New Revision: f8a3b9b06c4a46fe2a83ec52f8e396d335b44fdd

URL: 
https://github.com/llvm/llvm-project/commit/f8a3b9b06c4a46fe2a83ec52f8e396d335b44fdd
DIFF: 
https://github.com/llvm/llvm-project/commit/f8a3b9b06c4a46fe2a83ec52f8e396d335b44fdd.diff

LOG: [lldb] Correct vFile:pread/pwrite packet docs

The statement that lldb-server can handle
decimal and hex numbers is misleading.
(it can only handle hex with 0x prefix)

Mentioning non decimal numbers at all
is just creating more confusion for anyone
who tries to use them with lldb-server.

Differential Revision: https://reviews.llvm.org/D89383

Added: 


Modified: 
lldb/docs/lldb-platform-packets.txt

Removed: 




diff  --git a/lldb/docs/lldb-platform-packets.txt 
b/lldb/docs/lldb-platform-packets.txt
index e688fc92bb7e..5deb005aabf2 100644
--- a/lldb/docs/lldb-platform-packets.txt
+++ b/lldb/docs/lldb-platform-packets.txt
@@ -414,9 +414,8 @@ incompatible with the flags that gdb specifies.
 //
 //  COMPATIBILITY
 //The gdb-remote serial protocol documentation says that numbers
-//in "vFile:" packets should be hexidecimal. Instead lldb uses
-//decimal for the number of bytes and offset.
-//lldb-server can process either format.
+//in "vFile:" packets should be hexadecimal. Instead lldb uses
+//decimal.
 
 
 //--
@@ -439,8 +438,8 @@ incompatible with the flags that gdb specifies.
 //
 //  COMPATIBILITY
 //The gdb-remote serial protocol documentation says that numbers
-//in "vFile:" packets should be hexidecimal. Instead lldb uses
-//decimal for the offset. lldb-server can process either format.
+//in "vFile:" packets should be hexadecimal. Instead lldb uses
+//decimal.
 
 
 



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D89383: [lldb] Correct vFile:pread/pwrite packet docs

2020-10-27 Thread David Spickett via Phabricator via lldb-commits

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf8a3b9b06c4a: [lldb] Correct vFile:pread/pwrite packet docs 
(authored by DavidSpickett).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89383/new/

https://reviews.llvm.org/D89383

Files:
  lldb/docs/lldb-platform-packets.txt


Index: lldb/docs/lldb-platform-packets.txt
===
--- lldb/docs/lldb-platform-packets.txt
+++ lldb/docs/lldb-platform-packets.txt
@@ -414,9 +414,8 @@
 //
 //  COMPATIBILITY
 //The gdb-remote serial protocol documentation says that numbers
-//in "vFile:" packets should be hexidecimal. Instead lldb uses
-//decimal for the number of bytes and offset.
-//lldb-server can process either format.
+//in "vFile:" packets should be hexadecimal. Instead lldb uses
+//decimal.
 
 
 //--
@@ -439,8 +438,8 @@
 //
 //  COMPATIBILITY
 //The gdb-remote serial protocol documentation says that numbers
-//in "vFile:" packets should be hexidecimal. Instead lldb uses
-//decimal for the offset. lldb-server can process either format.
+//in "vFile:" packets should be hexadecimal. Instead lldb uses
+//decimal.
 
 
 


Index: lldb/docs/lldb-platform-packets.txt
===
--- lldb/docs/lldb-platform-packets.txt
+++ lldb/docs/lldb-platform-packets.txt
@@ -414,9 +414,8 @@
 //
 //  COMPATIBILITY
 //The gdb-remote serial protocol documentation says that numbers
-//in "vFile:" packets should be hexidecimal. Instead lldb uses
-//decimal for the number of bytes and offset.
-//lldb-server can process either format.
+//in "vFile:" packets should be hexadecimal. Instead lldb uses
+//decimal.
 
 
 //--
@@ -439,8 +438,8 @@
 //
 //  COMPATIBILITY
 //The gdb-remote serial protocol documentation says that numbers
-//in "vFile:" packets should be hexidecimal. Instead lldb uses
-//decimal for the offset. lldb-server can process either format.
+//in "vFile:" packets should be hexadecimal. Instead lldb uses
+//decimal.
 
 
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D89383: [lldb] Correct vFile:pread/pwrite packet docs

2020-10-27 Thread David Spickett via Phabricator via lldb-commits

DavidSpickett added a comment.

Landed as already agreed on in https://reviews.llvm.org/D89227.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89383/new/

https://reviews.llvm.org/D89383

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D90225: [lldb] Correct --help output for qemu rootfs script

2020-10-27 Thread David Spickett via Phabricator via lldb-commits

DavidSpickett created this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.
DavidSpickett requested review of this revision.
Herald added a subscriber: JDevlieghere.

It was printing "Usage:" twice.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90225

Files:
  lldb/scripts/lldb-test-qemu/rootfs.sh


Index: lldb/scripts/lldb-test-qemu/rootfs.sh
===
--- lldb/scripts/lldb-test-qemu/rootfs.sh
+++ lldb/scripts/lldb-test-qemu/rootfs.sh
@@ -3,7 +3,6 @@
 set -e
 
 print_usage() {
-  echo "Usage:"
   echo "Usage: $(basename $0) [options]"
   echo -e "Creates a Ubuntu root file system image.\n"
   echo -e "  --help\t\t\tDisplay this information."


Index: lldb/scripts/lldb-test-qemu/rootfs.sh
===
--- lldb/scripts/lldb-test-qemu/rootfs.sh
+++ lldb/scripts/lldb-test-qemu/rootfs.sh
@@ -3,7 +3,6 @@
 set -e
 
 print_usage() {
-  echo "Usage:"
   echo "Usage: $(basename $0) [options]"
   echo -e "Creates a Ubuntu root file system image.\n"
   echo -e "  --help\t\t\tDisplay this information."
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D90102: [lldb] [Process/FreeBSDRemote] Enable watchpoint support

2020-10-27 Thread Michał Górny via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG8e7ea99c3823: [lldb] [Process/FreeBSDRemote] Enable 
watchpoint support (authored by mgorny).
Herald added a project: LLDB.

Changed prior to commit:
  https://reviews.llvm.org/D90102?vs=300806&id=300984#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90102/new/

https://reviews.llvm.org/D90102

Files:
  lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp
  lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD.cpp
  lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD.h
  
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_x86_64.cpp
  
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_x86_64.h
  lldb/source/Plugins/Process/FreeBSDRemote/NativeThreadFreeBSD.cpp
  
lldb/test/API/commands/watchpoints/watchpoint_commands/command/TestWatchpointCommandPython.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentBreakpointDelayBreakpointOneSignal.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentBreakpointOneDelayBreakpointThreads.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentBreakpointsDelayedBreakpointOneWatchpoint.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentCrashWithBreak.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentCrashWithSignal.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentCrashWithWatchpoint.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentCrashWithWatchpointBreakpointSignal.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentDelaySignalBreak.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentDelaySignalWatch.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentDelayWatchBreak.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentDelayedCrashWithBreakpointSignal.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentDelayedCrashWithBreakpointWatchpoint.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentNWatchNBreak.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalBreak.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalDelayBreak.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalDelayWatch.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalNWatchNBreak.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalWatch.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalWatchBreak.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoBreakpointThreads.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoBreakpointsOneDelaySignal.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoBreakpointsOneSignal.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoBreakpointsOneWatchpoint.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointThreads.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneBreakpoint.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneDelayBreakpoint.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneSignal.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchBreak.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchBreakDelay.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchpointDelayWatchpointOneBreakpoint.py
  
lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchpointWithDelayWatchpointThreads.py
  lldb/test/API/lit.cfg.py

Index: lldb/test/API/lit.cfg.py
===
--- lldb/test/API/lit.cfg.py
+++ lldb/test/API/lit.cfg.py
@@ -257,3 +257,8 @@
 
 # testFormat: The test format to use to interpret tests.
 config.test_format = lldbtest.LLDBTest(dotest_cmd)
+
+# Propagate FREEBSD_REMOTE_PLUGIN
+if 'FREEBSD_REMOTE_PLUGIN' in os.environ:
+  config.environment['FREEBSD_REMOTE_PLUGIN'] = os.environ[
+  'FREEBSD_REMOTE_PLUGIN']
Index: lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchpointWithDelayWatchpointThreads.py
===
--- lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchpointWithDelayWatchpointThreads.py
+++ lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchpointWithDelayWatchpointThreads.py
@@ -11,7 +11,6 @@
 
 mydir = C

[Lldb-commits] [lldb] 8e7ea99 - [lldb] [Process/FreeBSDRemote] Enable watchpoint support

2020-10-27 Thread Michał Górny via lldb-commits


Author: Michał Górny
Date: 2020-10-27T15:38:00+01:00
New Revision: 8e7ea99c382300439486e562ba507d4a1bd6cc89

URL: 
https://github.com/llvm/llvm-project/commit/8e7ea99c382300439486e562ba507d4a1bd6cc89
DIFF: 
https://github.com/llvm/llvm-project/commit/8e7ea99c382300439486e562ba507d4a1bd6cc89.diff

LOG: [lldb] [Process/FreeBSDRemote] Enable watchpoint support

Replace the inline x86 watchpoint handling code with the reusable
NativeRegisterContextWatchpoint_x86.  Implement watchpoint support
in NativeThreadFreeBSD and SIGTRAP handling for watchpoints.

Un-skip all concurrent_events tests as they pass with the new plugin.

Differential Revision: https://reviews.llvm.org/D90102

Added: 


Modified: 
lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD.cpp
lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD.h

lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_x86_64.cpp

lldb/source/Plugins/Process/FreeBSDRemote/NativeRegisterContextFreeBSD_x86_64.h
lldb/source/Plugins/Process/FreeBSDRemote/NativeThreadFreeBSD.cpp

lldb/test/API/commands/watchpoints/watchpoint_commands/command/TestWatchpointCommandPython.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentBreakpointDelayBreakpointOneSignal.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentBreakpointOneDelayBreakpointThreads.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentBreakpointsDelayedBreakpointOneWatchpoint.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentCrashWithBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentCrashWithSignal.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentCrashWithWatchpoint.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentCrashWithWatchpointBreakpointSignal.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentDelaySignalBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentDelaySignalWatch.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentDelayWatchBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentDelayedCrashWithBreakpointSignal.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentDelayedCrashWithBreakpointWatchpoint.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentNWatchNBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalDelayBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalDelayWatch.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalNWatchNBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalWatch.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentSignalWatchBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoBreakpointThreads.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoBreakpointsOneDelaySignal.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoBreakpointsOneSignal.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoBreakpointsOneWatchpoint.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointThreads.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneBreakpoint.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneDelayBreakpoint.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentTwoWatchpointsOneSignal.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchBreak.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchBreakDelay.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchpointDelayWatchpointOneBreakpoint.py

lldb/test/API/functionalities/thread/concurrent_events/TestConcurrentWatchpointWithDelayWatchpointThreads.py
lldb/test/API/lit.cfg.py

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp 
b/lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp
index c234c0e023fb..0a4e8ed6bcbf 100644
--- a/lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp
+++ b/lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp
@@ -217,10 +217,8 @@ void NativeProcessFreeBSD::MonitorSIGTRAP(lldb::pid_t pid) 
{
 
   if (info.pl_lwpid > 0) {
 for (const au

[Lldb-commits] [lldb] 4ba8ea4 - [lldb] [Process/FreeBSD] Fix missing namespace qualifier

2020-10-27 Thread Michał Górny via lldb-commits


Author: Michał Górny
Date: 2020-10-27T15:38:00+01:00
New Revision: 4ba8ea4cb06758cb80dfa3d0409f7aab3d3f8e93

URL: 
https://github.com/llvm/llvm-project/commit/4ba8ea4cb06758cb80dfa3d0409f7aab3d3f8e93
DIFF: 
https://github.com/llvm/llvm-project/commit/4ba8ea4cb06758cb80dfa3d0409f7aab3d3f8e93.diff

LOG: [lldb] [Process/FreeBSD] Fix missing namespace qualifier

Fixes e4cc6e9bcdff5fe979ab72025cb803d723cd9c31

Added: 


Modified: 
lldb/source/Plugins/Process/FreeBSD/ProcessMonitor.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Process/FreeBSD/ProcessMonitor.cpp 
b/lldb/source/Plugins/Process/FreeBSD/ProcessMonitor.cpp
index e85470d81e2f..2c7c948f1059 100644
--- a/lldb/source/Plugins/Process/FreeBSD/ProcessMonitor.cpp
+++ b/lldb/source/Plugins/Process/FreeBSD/ProcessMonitor.cpp
@@ -826,7 +826,7 @@ bool ProcessMonitor::Launch(LaunchArgs *args) {
   Environment::Envp envp =
   (args->m_env.empty() ? Host::GetEnvironment() : args->m_env).getEnvp();
 
-  Expected pid = terminal.Fork();
+  llvm::Expected pid = terminal.Fork();
   if (!pid) {
 args->m_error = pid.takeError();
 goto FINISH;



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] d43c70a - [lldb] Add llvm-pdbutil to lldb test dependencies

2020-10-27 Thread Raphael Isemann via lldb-commits


Author: Raphael Isemann
Date: 2020-10-27T15:46:25+01:00
New Revision: d43c70a2025972c60dc1a30b4661273dc584d0b8

URL: 
https://github.com/llvm/llvm-project/commit/d43c70a2025972c60dc1a30b4661273dc584d0b8
DIFF: 
https://github.com/llvm/llvm-project/commit/d43c70a2025972c60dc1a30b4661273dc584d0b8.diff

LOG: [lldb] Add llvm-pdbutil to lldb test dependencies

Since D89812 we use llvm-pdbutil in the LLDB tests but we didn't add it to
the test dependencies.

Added: 


Modified: 
lldb/test/CMakeLists.txt

Removed: 




diff  --git a/lldb/test/CMakeLists.txt b/lldb/test/CMakeLists.txt
index 91665e7b..9d17009df2ca 100644
--- a/lldb/test/CMakeLists.txt
+++ b/lldb/test/CMakeLists.txt
@@ -141,6 +141,7 @@ add_lldb_test_dependency(
   llvm-nm
   llvm-mc
   llvm-objcopy
+  llvm-pdbutil
   llvm-readobj
   )
 



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 45c3fc9 - [lldb][NFC] Make GetResumeCountForLaunchInfo return an unsigned.

2020-10-27 Thread Raphael Isemann via lldb-commits


Author: Raphael Isemann
Date: 2020-10-27T16:25:01+01:00
New Revision: 45c3fc97a2a5af760a55e72eb081aa5f977e9609

URL: 
https://github.com/llvm/llvm-project/commit/45c3fc97a2a5af760a55e72eb081aa5f977e9609
DIFF: 
https://github.com/llvm/llvm-project/commit/45c3fc97a2a5af760a55e72eb081aa5f977e9609.diff

LOG: [lldb][NFC] Make GetResumeCountForLaunchInfo return an unsigned.

The number of resumes should always be positive to let's make this an
unsigned everywhere. Also remove the unused 'localhost' parameter from
ConvertArgumentsForLaunchingInShell.

Added: 


Modified: 
lldb/include/lldb/Host/ProcessLaunchInfo.h
lldb/include/lldb/Target/Platform.h
lldb/source/Host/common/Host.cpp
lldb/source/Host/common/ProcessLaunchInfo.cpp
lldb/source/Plugins/Platform/Linux/PlatformLinux.cpp
lldb/source/Plugins/Platform/Linux/PlatformLinux.h
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
lldb/source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp
lldb/source/Plugins/Platform/NetBSD/PlatformNetBSD.h
lldb/source/Target/Platform.cpp

Removed: 




diff  --git a/lldb/include/lldb/Host/ProcessLaunchInfo.h 
b/lldb/include/lldb/Host/ProcessLaunchInfo.h
index e83d8396e9f2..ee9755580825 100644
--- a/lldb/include/lldb/Host/ProcessLaunchInfo.h
+++ b/lldb/include/lldb/Host/ProcessLaunchInfo.h
@@ -94,10 +94,9 @@ class ProcessLaunchInfo : public ProcessInfo {
 
   void Clear();
 
-  bool ConvertArgumentsForLaunchingInShell(Status &error, bool localhost,
-   bool will_debug,
+  bool ConvertArgumentsForLaunchingInShell(Status &error, bool will_debug,
bool 
first_arg_is_full_shell_command,
-   int32_t num_resumes);
+   uint32_t num_resumes);
 
   void
   SetMonitorProcessCallback(const Host::MonitorChildProcessCallback &callback,

diff  --git a/lldb/include/lldb/Target/Platform.h 
b/lldb/include/lldb/Target/Platform.h
index f371b8153144..3c480641a275 100644
--- a/lldb/include/lldb/Target/Platform.h
+++ b/lldb/include/lldb/Target/Platform.h
@@ -651,7 +651,7 @@ class Platform : public PluginInterface {
   virtual bool CalculateMD5(const FileSpec &file_spec, uint64_t &low,
 uint64_t &high);
 
-  virtual int32_t GetResumeCountForLaunchInfo(ProcessLaunchInfo &launch_info) {
+  virtual uint32_t GetResumeCountForLaunchInfo(ProcessLaunchInfo &launch_info) 
{
 return 1;
   }
 

diff  --git a/lldb/source/Host/common/Host.cpp 
b/lldb/source/Host/common/Host.cpp
index 958fca07850b..99316660908e 100644
--- a/lldb/source/Host/common/Host.cpp
+++ b/lldb/source/Host/common/Host.cpp
@@ -514,11 +514,10 @@ Status Host::RunShellCommand(llvm::StringRef shell_path, 
const Args &args,
 
 launch_info.SetShell(shell);
 launch_info.GetArguments().AppendArguments(args);
-const bool localhost = true;
 const bool will_debug = false;
 const bool first_arg_is_full_shell_command = false;
 launch_info.ConvertArgumentsForLaunchingInShell(
-error, localhost, will_debug, first_arg_is_full_shell_command, 0);
+error, will_debug, first_arg_is_full_shell_command, 0);
   } else {
 // No shell, just run it
 const bool first_arg_is_executable = true;

diff  --git a/lldb/source/Host/common/ProcessLaunchInfo.cpp 
b/lldb/source/Host/common/ProcessLaunchInfo.cpp
index 01cf3d76314e..1b4b2c6c3ac2 100644
--- a/lldb/source/Host/common/ProcessLaunchInfo.cpp
+++ b/lldb/source/Host/common/ProcessLaunchInfo.cpp
@@ -241,8 +241,8 @@ llvm::Error ProcessLaunchInfo::SetUpPtyRedirection() {
 }
 
 bool ProcessLaunchInfo::ConvertArgumentsForLaunchingInShell(
-Status &error, bool localhost, bool will_debug,
-bool first_arg_is_full_shell_command, int32_t num_resumes) {
+Status &error, bool will_debug, bool first_arg_is_full_shell_command,
+uint32_t num_resumes) {
   error.Clear();
 
   if (GetFlags().Test(eLaunchFlagLaunchInShell)) {

diff  --git a/lldb/source/Plugins/Platform/Linux/PlatformLinux.cpp 
b/lldb/source/Plugins/Platform/Linux/PlatformLinux.cpp
index 5eb0508de32c..2cb671fd4dc3 100644
--- a/lldb/source/Plugins/Platform/Linux/PlatformLinux.cpp
+++ b/lldb/source/Plugins/Platform/Linux/PlatformLinux.cpp
@@ -216,9 +216,9 @@ void PlatformLinux::GetStatus(Stream &strm) {
 #endif
 }
 
-int32_t
+uint32_t
 PlatformLinux::GetResumeCountForLaunchInfo(ProcessLaunchInfo &launch_info) {
-  int32_t resume_count = 0;
+  uint32_t resume_count = 0;
 
   // Always resume past the initial stop when we use eLaunchFlagDebug
   if (launch_info.GetFlags().Test(eLaunchFlagDebug)) {

diff  --git a/lldb/source/Plugins/Platform/Linux/PlatformLinux.h 
b/lldb/source/Plugins/Platform/Linux/PlatformLinux.h
index 81175d7c5cab..cbbd226c13a8 100644
--- a/lldb/source/Plugins/Platform/Linux/P

[Lldb-commits] [PATCH] D89334: [lldb] Support Python imports relative the to the current file being sourced

2020-10-27 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added a comment.

In D89334#2355870 , @labath wrote:

> Let's see how this goes.

Thanks for bearing with me :-)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89334/new/

https://reviews.llvm.org/D89334

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D89334: [lldb] Support Python imports relative the to the current file being sourced

2020-10-27 Thread Jonas Devlieghere via Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG00bb397b0dc7: [lldb] Support Python imports relative the to 
the current file being sourced (authored by JDevlieghere).
Herald added a project: LLDB.

Changed prior to commit:
  https://reviews.llvm.org/D89334?vs=300803&id=301030#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89334/new/

https://reviews.llvm.org/D89334

Files:
  lldb/include/lldb/Interpreter/CommandInterpreter.h
  lldb/include/lldb/Interpreter/ScriptInterpreter.h
  lldb/source/Commands/CommandObjectCommands.cpp
  lldb/source/Commands/Options.td
  lldb/source/Interpreter/CommandInterpreter.cpp
  lldb/source/Interpreter/ScriptInterpreter.cpp
  lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
  lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.h
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
  lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
  lldb/test/Shell/ScriptInterpreter/Python/Inputs/hello.split
  lldb/test/Shell/ScriptInterpreter/Python/Inputs/relative.split
  lldb/test/Shell/ScriptInterpreter/Python/command_relative_import.test

Index: lldb/test/Shell/ScriptInterpreter/Python/command_relative_import.test
===
--- /dev/null
+++ lldb/test/Shell/ScriptInterpreter/Python/command_relative_import.test
@@ -0,0 +1,31 @@
+# REQUIRES: python
+
+# RUN: rm -rf %t && mkdir -p %t/foo/bar/baz
+# RUN: split-file %S/Inputs/relative.split %t/foo
+# RUN: split-file %S/Inputs/hello.split %t/foo/bar
+# RUN: mv %t/foo/bar/hello.py %t/foo/bar/baz
+# RUN: echo 'command source %t/foo/bar/hello.in' >> %t/foo/zip.in
+
+# RUN: %lldb --script-language python \
+# RUN:-o 'command source %t/foo/magritte.in' \
+# RUN:-o 'command source %t/foo/zip.in' \
+# RUN:-o 'command source %t/foo/magritte.in' \
+# RUN;-o 'zip' \
+# RUN:-o 'hello'
+# RUN -o 'magritte' 2>&1 | FileCheck %s
+
+# The first time importing 'magritte' fails because we didn't pass -c.
+# CHECK: ModuleNotFoundError: No module named 'magritte'
+# CHECK-NOT: Ceci n'est pas une pipe
+# CHECK: 95126
+# CHECK: Hello, World!
+# The second time importing 'magritte' works, even without passing -c because
+# we added '%t/foo' to the Python path when importing 'zip'.
+# CHECK: Ceci n'est pas une pipe
+
+# Cannot use `-o` here because the driver puts the commands in a file and
+# sources them.
+command script import -c %t/foo/magritte.py
+quit
+# RUN: cat %s | %lldb --script-language python 2>&1 | FileCheck %s --check-prefix ERROR
+# ERROR: error: command script import -c can only be specified from a command file
Index: lldb/test/Shell/ScriptInterpreter/Python/Inputs/relative.split
===
--- /dev/null
+++ lldb/test/Shell/ScriptInterpreter/Python/Inputs/relative.split
@@ -0,0 +1,20 @@
+#--- magritte.in
+command script import magritte
+#--- magritte.py
+import lldb
+
+def magritte(debugger, command, result, internal_dict):
+print("Ceci n'est pas une pipe")
+
+def __lldb_init_module(debugger, internal_dict):
+debugger.HandleCommand('command script add -f magritte.magritte magritte')
+#--- zip.in
+command script import -c zip
+#--- zip.py
+import lldb
+
+def zip(debugger, command, result, internal_dict):
+print("95126")
+
+def __lldb_init_module(debugger, internal_dict):
+debugger.HandleCommand('command script add -f zip.zip zip')
Index: lldb/test/Shell/ScriptInterpreter/Python/Inputs/hello.split
===
--- /dev/null
+++ lldb/test/Shell/ScriptInterpreter/Python/Inputs/hello.split
@@ -0,0 +1,10 @@
+#--- hello.in
+command script import -c baz.hello
+#--- hello.py
+import lldb
+
+def hello(debugger, command, result, internal_dict):
+print("Hello, World!")
+
+def __lldb_init_module(debugger, internal_dict):
+debugger.HandleCommand('command script add -f baz.hello.hello hello')
Index: lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
===
--- lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
+++ lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
@@ -231,10 +231,10 @@
   bool RunScriptFormatKeyword(const char *impl_function, ValueObject *value,
   std::string &output, Status &error) override;
 
-  bool
-  LoadScriptingModule(const char *filename, bool init_session,
-  lldb_private::Status &error,
-  StructuredData::ObjectSP *module_sp = nullptr) override;
+  bool LoadScriptingModule(const char *filename, bool init_session,
+   lldb_private::Status &error,
+   StructuredData::ObjectSP *module_sp = nullptr,
+

[Lldb-commits] [lldb] 00bb397 - [lldb] Support Python imports relative the to the current file being sourced

2020-10-27 Thread Jonas Devlieghere via lldb-commits


Author: Jonas Devlieghere
Date: 2020-10-27T09:20:45-07:00
New Revision: 00bb397b0dc79fcad27bfe63456a2100039706f2

URL: 
https://github.com/llvm/llvm-project/commit/00bb397b0dc79fcad27bfe63456a2100039706f2
DIFF: 
https://github.com/llvm/llvm-project/commit/00bb397b0dc79fcad27bfe63456a2100039706f2.diff

LOG: [lldb] Support Python imports relative the to the current file being 
sourced

Make it possible to use a relative path in command script import to the
location of the file being sourced. This allows the user to put Python
scripts next to LLDB command files and importing them without having to
specify an absolute path.

To enable this behavior pass `-c` to `command script import`. The
argument can only be used when sourcing the command from a file.

rdar://68310384

Differential revision: https://reviews.llvm.org/D89334

Added: 
lldb/test/Shell/ScriptInterpreter/Python/Inputs/hello.split
lldb/test/Shell/ScriptInterpreter/Python/Inputs/relative.split
lldb/test/Shell/ScriptInterpreter/Python/command_relative_import.test

Modified: 
lldb/include/lldb/Interpreter/CommandInterpreter.h
lldb/include/lldb/Interpreter/ScriptInterpreter.h
lldb/source/Commands/CommandObjectCommands.cpp
lldb/source/Commands/Options.td
lldb/source/Interpreter/CommandInterpreter.cpp
lldb/source/Interpreter/ScriptInterpreter.cpp
lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.cpp
lldb/source/Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.h
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h

Removed: 




diff  --git a/lldb/include/lldb/Interpreter/CommandInterpreter.h 
b/lldb/include/lldb/Interpreter/CommandInterpreter.h
index f899861bb218..d35f7e22b9ea 100644
--- a/lldb/include/lldb/Interpreter/CommandInterpreter.h
+++ b/lldb/include/lldb/Interpreter/CommandInterpreter.h
@@ -551,6 +551,8 @@ class CommandInterpreter : public Broadcaster,
   bool SaveTranscript(CommandReturnObject &result,
   llvm::Optional output_file = llvm::None);
 
+  FileSpec GetCurrentSourceDir();
+
 protected:
   friend class Debugger;
 
@@ -637,7 +639,13 @@ class CommandInterpreter : public Broadcaster,
   ChildrenTruncatedWarningStatus m_truncation_warning; // Whether we truncated
// children and whether
// the user has been 
told
+
+  // FIXME: Stop using this to control adding to the history and then replace
+  // this with m_command_source_dirs.size().
   uint32_t m_command_source_depth;
+  /// A stack of directory paths. When not empty, the last one is the directory
+  /// of the file that's currently sourced.
+  std::vector m_command_source_dirs;
   std::vector m_command_source_flags;
   CommandInterpreterRunResult m_result;
 

diff  --git a/lldb/include/lldb/Interpreter/ScriptInterpreter.h 
b/lldb/include/lldb/Interpreter/ScriptInterpreter.h
index c38786fd50d4..4abd1ca68167 100644
--- a/lldb/include/lldb/Interpreter/ScriptInterpreter.h
+++ b/lldb/include/lldb/Interpreter/ScriptInterpreter.h
@@ -507,7 +507,8 @@ class ScriptInterpreter : public PluginInterface {
   virtual bool
   LoadScriptingModule(const char *filename, bool init_session,
   lldb_private::Status &error,
-  StructuredData::ObjectSP *module_sp = nullptr);
+  StructuredData::ObjectSP *module_sp = nullptr,
+  FileSpec extra_search_dir = {});
 
   virtual bool IsReservedWord(const char *word) { return false; }
 

diff  --git a/lldb/source/Commands/CommandObjectCommands.cpp 
b/lldb/source/Commands/CommandObjectCommands.cpp
index 96ce82d84248..0c441dd69c48 100644
--- a/lldb/source/Commands/CommandObjectCommands.cpp
+++ b/lldb/source/Commands/CommandObjectCommands.cpp
@@ -1272,6 +1272,9 @@ class CommandObjectCommandsScriptImport : public 
CommandObjectParsed {
   case 'r':
 // NO-OP
 break;
+  case 'c':
+relative_to_command_file = true;
+break;
   default:
 llvm_unreachable("Unimplemented option");
   }
@@ -1280,11 +1283,13 @@ class CommandObjectCommandsScriptImport : public 
CommandObjectParsed {
 }
 
 void OptionParsingStarting(ExecutionContext *execution_context) override {
+  relative_to_command_file = false;
 }
 
 llvm::ArrayRef GetDefinitions() override {
   return llvm::makeArrayRef(g_script_import_options);
 }
+bool relative_to_command_file = false;
   };
 
   bool DoExecute(Args &command, CommandReturnObject &result) override {
@@ -1294,6 +1299,17 @@ class CommandObjectCommandsScriptImport : public 
CommandObjectParsed {
   return false;
 }
 
+FileSpec source_dir = {};
+if (m_options.relative_to_command_file) {
+  source_dir =

[Lldb-commits] [PATCH] D89283: [trace][intel-pt] Implement the basic decoding functionality

2020-10-27 Thread Vedant Kumar via Phabricator via lldb-commits

vsk added a comment.

@wallace thanks for winnowing the test objects. I left an inline suggestion 
about simplifying the error-handling in IntelPTInstruction. Other than that, 
mechanically this is looking good. Thanks!




Comment at: lldb/source/Plugins/Trace/intel-pt/DecodedThread.h:36
+
+  IntelPTInstruction(const pt_insn &pt_insn, int libipt_error_code = 0)
+  : m_pt_insn(pt_insn), m_libipt_error_code(libipt_error_code),

Does this IntelPTInstruction constructor ever get called with a non-zero libipt 
error code?



Comment at: lldb/source/Plugins/Trace/intel-pt/DecodedThread.h:40
+
+  IntelPTInstruction(int libipt_error_code)
+  : m_pt_insn(), m_libipt_error_code(libipt_error_code), m_custom_error() 
{}

It might be a bit cleaner to just have two IntelPTInstruction constructors: one 
that accepts a `const pt_insn &` and another that accepts an `llvm::Error`. To 
do that, you'd need to introduce a PT-specific ErrorInfo (`class IntelPTError : 
public ErrorInfo { ... }`). This can wrap some sort of generic 
error (as a std::string, perhaps), or a libipt-specific error.

It'd be a little more up front work, but the benefit is that it simplifies 
error handling (there's just one type of error, only one error value to check 
in IsError, etc).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89283/new/

https://reviews.llvm.org/D89283

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D88483: Add possibility to get module from SBType

2020-10-27 Thread Ilya Bukonkin via Phabricator via lldb-commits

fallkrum added a comment.

@JDevlieghere ping


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88483/new/

https://reviews.llvm.org/D88483

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D88483: Add possibility to get module from SBType

2020-10-27 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere accepted this revision.
JDevlieghere added a comment.
This revision is now accepted and ready to land.

LGTM with the few nits addressed.




Comment at: lldb/include/lldb/Symbol/Type.h:269
 
+  lldb::ModuleSP GetModule();
+





Comment at: lldb/test/API/functionalities/type_get_module/Makefile:1
+
+C_SOURCES := main.c compile_unit1.c compile_unit2.c

spurious newline?



Comment at: lldb/test/API/functionalities/type_get_module/compile_unit1.c:1
+
+struct compile_unit1_type {

spurious newline?



Comment at: lldb/test/API/functionalities/type_get_module/compile_unit2.c:1
+
+struct compile_unit2_type {

spurious newline?



Comment at: lldb/test/API/functionalities/type_get_module/main.c:1
+
+int main() { return 0; }

spurious newline?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88483/new/

https://reviews.llvm.org/D88483

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] Upcoming upgrade of LLVM buildbot

2020-10-27 Thread Vitaly Buka via lldb-commits

Any news regarding false-negatives?

+Mitch Phillips 

On Mon, 19 Oct 2020 at 22:07, Galina Kistanova  wrote:

> Thanks, Vitaly.
> Somebody is looking at this.
>
>
> On Mon, Oct 19, 2020 at 9:56 PM Vitaly Buka  wrote:
>
>> it's not just staging, this build must be marked as failed
>> http://lab.llvm.org:8011/#/builders/74/builds/122
>>
>>
>> On Mon, 19 Oct 2020 at 11:50, Vitaly Buka  wrote:
>>
>>> There is some issue, at least on staging.
>>> http://lab.llvm.org:8014/#/builders/89/builds/184 has multiple failed
>>> stages but marked as SUCCESS
>>>
>>>
>>> On Mon, 19 Oct 2020 at 11:43, Vitaly Buka  wrote:
>>>
 Thanks!
 Done.

 On Sat, 17 Oct 2020 at 12:45, Galina Kistanova 
 wrote:

> Thanks everyone for keeping your annotated builders in the staging
> area! Much appreciated.
>
> Please feel free to move all the green builders back to the
> production. It has a new AnnotatedCommand now.
>
> Thanks
>
> Galina
>
>
> On Thu, Oct 15, 2020 at 12:46 AM Vitaly Buka 
> wrote:
>
>> Ok, I can switch them back to staging. However today's staging was
>> frequently offline.
>>
>>
>> On Wed, 14 Oct 2020 at 21:44, Galina Kistanova 
>> wrote:
>>
>>> Thanks everyone!
>>>
>>> I would like to keep the bots in the staging till Friday. And if
>>> everything is good, then apply the changes to the production and let you
>>> move all the green bots back there.
>>>
>>> Thanks
>>>
>>> Galina
>>>
>>>
>>> On Tue, Oct 13, 2020 at 10:43 PM Vitaly Buka 
>>> wrote:
>>>
 They do on staging.
 http://lab.llvm.org:8014/#/builders/sanitizer-windows
 http://lab.llvm.org:8014/#/builders/clang-x64-windows-msvc

 Galina, when do you plan to push this to the primary server?
 If it's a few days, I'd rather keep bots on staging to have colors.



 On Tue, 13 Oct 2020 at 11:11, Reid Kleckner  wrote:

> FWIW, I don't see any issues with my two bots that use buildbot
> annotated commands:
> http://lab.llvm.org:8011/#/builders/sanitizer-windows
> http://lab.llvm.org:8011/#/builders/clang-x64-windows-msvc
> The individual steps don't highlight as green or red, but that's
> OK for now.
>
> On Mon, Oct 12, 2020 at 7:19 PM Galina Kistanova <
> gkistan...@gmail.com> wrote:
>
>> We have a better version of AnnotatedCommand on the staging. It
>> should be a functional equivalent of the old one.
>> We need to stress test it well before moving to the production
>> build bot.
>>
>> For that we need all sanitizer + other bots which use the
>> AnnotatedCommand directly or indirectly moved temporarily to the 
>> staging.
>>
>> Please let me know when that could be arranged.
>>
>> Thanks
>>
>> Galina
>>
>> On Mon, Oct 12, 2020 at 11:39 AM Reid Kleckner 
>> wrote:
>>
>>> On Wed, Oct 7, 2020 at 4:32 PM Galina Kistanova via lldb-commits
>>>  wrote:
>>>
 They are online now -
 http://lab.llvm.org:8011/#/waterfall?tags=sanitizer

 AnnotatedCommand has severe design conflict with the new
 buildbot.
 We have changed it to be safe and still do something useful,
 but it will need more love and care.

 Please let me know if you have some spare time to work on
 porting AnnotatedCommand.

>>>
>>> That's unfortunate, it would've been good to know that earlier.
>>> I and another team member have spent a fair amount of time porting 
>>> things
>>> to use more AnnotatedCommand steps, because it gives us the 
>>> flexibility to
>>> test steps locally and make changes to the steps without restarting 
>>> the
>>> buildbot master. IMO that is the Right Way to define steps: a 
>>> script that
>>> you can run locally on a machine that satisfies the OS and dep 
>>> requirements
>>> of the script.
>>>
>>> I am restarting the two bots that I am responsible for, and may
>>> need some help debugging further issues soon. I'll let you know.
>>>
>>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] Upcoming upgrade of LLVM buildbot

2020-10-27 Thread Vitaly Buka via lldb-commits

It looks fixed. I haven't seen them in recent reports.

On Tue, 27 Oct 2020 at 16:32, Vitaly Buka  wrote:

> Any news regarding false-negatives?
>
> +Mitch Phillips 
>
> On Mon, 19 Oct 2020 at 22:07, Galina Kistanova 
> wrote:
>
>> Thanks, Vitaly.
>> Somebody is looking at this.
>>
>>
>> On Mon, Oct 19, 2020 at 9:56 PM Vitaly Buka 
>> wrote:
>>
>>> it's not just staging, this build must be marked as failed
>>> http://lab.llvm.org:8011/#/builders/74/builds/122
>>>
>>>
>>> On Mon, 19 Oct 2020 at 11:50, Vitaly Buka  wrote:
>>>
 There is some issue, at least on staging.
 http://lab.llvm.org:8014/#/builders/89/builds/184 has multiple failed
 stages but marked as SUCCESS


 On Mon, 19 Oct 2020 at 11:43, Vitaly Buka 
 wrote:

> Thanks!
> Done.
>
> On Sat, 17 Oct 2020 at 12:45, Galina Kistanova 
> wrote:
>
>> Thanks everyone for keeping your annotated builders in the staging
>> area! Much appreciated.
>>
>> Please feel free to move all the green builders back to the
>> production. It has a new AnnotatedCommand now.
>>
>> Thanks
>>
>> Galina
>>
>>
>> On Thu, Oct 15, 2020 at 12:46 AM Vitaly Buka 
>> wrote:
>>
>>> Ok, I can switch them back to staging. However today's staging was
>>> frequently offline.
>>>
>>>
>>> On Wed, 14 Oct 2020 at 21:44, Galina Kistanova 
>>> wrote:
>>>
 Thanks everyone!

 I would like to keep the bots in the staging till Friday. And if
 everything is good, then apply the changes to the production and let 
 you
 move all the green bots back there.

 Thanks

 Galina


 On Tue, Oct 13, 2020 at 10:43 PM Vitaly Buka 
 wrote:

> They do on staging.
> http://lab.llvm.org:8014/#/builders/sanitizer-windows
> http://lab.llvm.org:8014/#/builders/clang-x64-windows-msvc
>
> Galina, when do you plan to push this to the primary server?
> If it's a few days, I'd rather keep bots on staging to have colors.
>
>
>
> On Tue, 13 Oct 2020 at 11:11, Reid Kleckner 
> wrote:
>
>> FWIW, I don't see any issues with my two bots that use buildbot
>> annotated commands:
>> http://lab.llvm.org:8011/#/builders/sanitizer-windows
>> http://lab.llvm.org:8011/#/builders/clang-x64-windows-msvc
>> The individual steps don't highlight as green or red, but that's
>> OK for now.
>>
>> On Mon, Oct 12, 2020 at 7:19 PM Galina Kistanova <
>> gkistan...@gmail.com> wrote:
>>
>>> We have a better version of AnnotatedCommand on the staging. It
>>> should be a functional equivalent of the old one.
>>> We need to stress test it well before moving to the production
>>> build bot.
>>>
>>> For that we need all sanitizer + other bots which use the
>>> AnnotatedCommand directly or indirectly moved temporarily to the 
>>> staging.
>>>
>>> Please let me know when that could be arranged.
>>>
>>> Thanks
>>>
>>> Galina
>>>
>>> On Mon, Oct 12, 2020 at 11:39 AM Reid Kleckner 
>>> wrote:
>>>
 On Wed, Oct 7, 2020 at 4:32 PM Galina Kistanova via
 lldb-commits  wrote:

> They are online now -
> http://lab.llvm.org:8011/#/waterfall?tags=sanitizer
>
> AnnotatedCommand has severe design conflict with the new
> buildbot.
> We have changed it to be safe and still do something useful,
> but it will need more love and care.
>
> Please let me know if you have some spare time to work on
> porting AnnotatedCommand.
>

 That's unfortunate, it would've been good to know that earlier.
 I and another team member have spent a fair amount of time porting 
 things
 to use more AnnotatedCommand steps, because it gives us the 
 flexibility to
 test steps locally and make changes to the steps without 
 restarting the
 buildbot master. IMO that is the Right Way to define steps: a 
 script that
 you can run locally on a machine that satisfies the OS and dep 
 requirements
 of the script.

 I am restarting the two bots that I am responsible for, and may
 need some help debugging further issues soon. I'll let you know.

>>>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D89283: [trace][intel-pt] Implement the basic decoding functionality

2020-10-27 Thread walter erquinigo via Phabricator via lldb-commits

wallace updated this revision to Diff 301128.
wallace added a comment.

Followed @vsk's suggestion. I didn't do exactly what he said, but I ended up 
creating my own IntelPTError to represent better the different kinds of errors 
and make sure we can create a correct llvm::Error when traversing the 
instructions.
The IntelPTInstruction code is much simpler now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89283/new/

https://reviews.llvm.org/D89283

Files:
  lldb/include/lldb/Core/Disassembler.h
  lldb/include/lldb/Symbol/SymbolContext.h
  lldb/include/lldb/Target/Trace.h
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/source/Commands/CommandObjectThread.cpp
  lldb/source/Commands/Options.td
  lldb/source/Core/Disassembler.cpp
  lldb/source/Plugins/Trace/intel-pt/CMakeLists.txt
  lldb/source/Plugins/Trace/intel-pt/DecodedThread.cpp
  lldb/source/Plugins/Trace/intel-pt/DecodedThread.h
  lldb/source/Plugins/Trace/intel-pt/IntelPTDecoder.cpp
  lldb/source/Plugins/Trace/intel-pt/IntelPTDecoder.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
  lldb/source/Symbol/SymbolContext.cpp
  lldb/source/Target/ProcessTrace.cpp
  lldb/source/Target/Trace.cpp
  lldb/source/Target/TraceSessionFileParser.cpp
  lldb/test/API/commands/trace/TestTraceDumpInstructions.py
  lldb/test/API/commands/trace/intelpt-trace-multi-file/a.out
  lldb/test/API/commands/trace/intelpt-trace-multi-file/bar.cpp
  lldb/test/API/commands/trace/intelpt-trace-multi-file/bar.h
  lldb/test/API/commands/trace/intelpt-trace-multi-file/foo.cpp
  lldb/test/API/commands/trace/intelpt-trace-multi-file/foo.h
  lldb/test/API/commands/trace/intelpt-trace-multi-file/libbar.so
  lldb/test/API/commands/trace/intelpt-trace-multi-file/libfoo.so
  lldb/test/API/commands/trace/intelpt-trace-multi-file/main.cpp
  lldb/test/API/commands/trace/intelpt-trace-multi-file/multi-file-no-ld.json
  lldb/test/API/commands/trace/intelpt-trace-multi-file/multi-file.trace
  lldb/test/API/commands/trace/intelpt-trace/trace_bad_image.json
  lldb/test/API/commands/trace/intelpt-trace/trace_wrong_cpu.json

Index: lldb/test/API/commands/trace/intelpt-trace/trace_wrong_cpu.json
===
--- /dev/null
+++ lldb/test/API/commands/trace/intelpt-trace/trace_wrong_cpu.json
@@ -0,0 +1,31 @@
+{
+  "trace": {
+"type": "intel-pt",
+"pt_cpu": {
+  "vendor": "intel",
+  "family": 2123123,
+  "model": 12123123,
+  "stepping": 1231231
+}
+  },
+  "processes": [
+{
+  "pid": 1234,
+  "triple": "x86_64-*-linux",
+  "threads": [
+{
+  "tid": 3842849,
+  "traceFile": "3842849.trace"
+}
+  ],
+  "modules": [
+{
+  "file": "a.out",
+  "systemPath": "a.out",
+  "loadAddress": "0x0040",
+  "uuid": "6AA9A4E2-6F28-2F33-377D-59FECE874C71-5B41261A"
+}
+  ]
+}
+  ]
+}
Index: lldb/test/API/commands/trace/intelpt-trace/trace_bad_image.json
===
--- /dev/null
+++ lldb/test/API/commands/trace/intelpt-trace/trace_bad_image.json
@@ -0,0 +1,31 @@
+{
+  "trace": {
+"type": "intel-pt",
+"pt_cpu": {
+  "vendor": "intel",
+  "family": 6,
+  "model": 79,
+  "stepping": 1
+}
+  },
+  "processes": [
+{
+  "pid": 1234,
+  "triple": "x86_64-*-linux",
+  "threads": [
+{
+  "tid": 3842849,
+  "traceFile": "3842849.trace"
+}
+  ],
+  "modules": [
+{
+  "file": "a.out",
+  "systemPath": "a.out",
+  "loadAddress": "0x00F0",
+  "uuid": "6AA9A4E2-6F28-2F33-377D-59FECE874C71-5B41261A"
+}
+  ]
+}
+  ]
+}
Index: lldb/test/API/commands/trace/intelpt-trace-multi-file/multi-file-no-ld.json
===
--- /dev/null
+++ lldb/test/API/commands/trace/intelpt-trace-multi-file/multi-file-no-ld.json
@@ -0,0 +1,43 @@
+{
+  "trace": {
+"type": "intel-pt",
+"pt_cpu": {
+  "vendor": "intel",
+  "family": 6,
+  "model": 79,
+  "stepping": 1
+}
+  },
+  "processes": [
+{
+  "pid": 815455,
+  "triple": "x86_64-*-linux",
+  "threads": [
+{
+  "tid": 815455,
+  "traceFile": "multi-file.trace"
+}
+  ],
+  "modules": [
+{
+  "file": "a.out",
+  "systemPath": "a.out",
+  "loadAddress": "0x0040",
+  "uuid": "D2414468-7112-B7C5-408D-FF07E30D5B17-A5BFD2C4"
+},
+{
+  "file": "libfoo.so",
+  "systemPath": "libfoo.so",
+  "loadAddress": "0x77bd9000",
+  "uuid": "B30FFEDA-8BB2-3D08-4580-C5937ED11E2B-21BE778C"
+},
+{
+  "file": "libbar.so",
+  "systemPath":

[Lldb-commits] [PATCH] D89283: [trace][intel-pt] Implement the basic decoding functionality

2020-10-27 Thread walter erquinigo via Phabricator via lldb-commits

wallace updated this revision to Diff 301130.
wallace added a comment.

nits


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89283/new/

https://reviews.llvm.org/D89283

Files:
  lldb/include/lldb/Core/Disassembler.h
  lldb/include/lldb/Symbol/SymbolContext.h
  lldb/include/lldb/Target/Trace.h
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/source/Commands/CommandObjectThread.cpp
  lldb/source/Commands/Options.td
  lldb/source/Core/Disassembler.cpp
  lldb/source/Plugins/Trace/intel-pt/CMakeLists.txt
  lldb/source/Plugins/Trace/intel-pt/DecodedThread.cpp
  lldb/source/Plugins/Trace/intel-pt/DecodedThread.h
  lldb/source/Plugins/Trace/intel-pt/IntelPTDecoder.cpp
  lldb/source/Plugins/Trace/intel-pt/IntelPTDecoder.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
  lldb/source/Symbol/SymbolContext.cpp
  lldb/source/Target/ProcessTrace.cpp
  lldb/source/Target/Trace.cpp
  lldb/source/Target/TraceSessionFileParser.cpp
  lldb/test/API/commands/trace/TestTraceDumpInstructions.py
  lldb/test/API/commands/trace/intelpt-trace-multi-file/a.out
  lldb/test/API/commands/trace/intelpt-trace-multi-file/bar.cpp
  lldb/test/API/commands/trace/intelpt-trace-multi-file/bar.h
  lldb/test/API/commands/trace/intelpt-trace-multi-file/foo.cpp
  lldb/test/API/commands/trace/intelpt-trace-multi-file/foo.h
  lldb/test/API/commands/trace/intelpt-trace-multi-file/libbar.so
  lldb/test/API/commands/trace/intelpt-trace-multi-file/libfoo.so
  lldb/test/API/commands/trace/intelpt-trace-multi-file/main.cpp
  lldb/test/API/commands/trace/intelpt-trace-multi-file/multi-file-no-ld.json
  lldb/test/API/commands/trace/intelpt-trace-multi-file/multi-file.trace
  lldb/test/API/commands/trace/intelpt-trace/trace_bad_image.json
  lldb/test/API/commands/trace/intelpt-trace/trace_wrong_cpu.json

Index: lldb/test/API/commands/trace/intelpt-trace/trace_wrong_cpu.json
===
--- /dev/null
+++ lldb/test/API/commands/trace/intelpt-trace/trace_wrong_cpu.json
@@ -0,0 +1,31 @@
+{
+  "trace": {
+"type": "intel-pt",
+"pt_cpu": {
+  "vendor": "intel",
+  "family": 2123123,
+  "model": 12123123,
+  "stepping": 1231231
+}
+  },
+  "processes": [
+{
+  "pid": 1234,
+  "triple": "x86_64-*-linux",
+  "threads": [
+{
+  "tid": 3842849,
+  "traceFile": "3842849.trace"
+}
+  ],
+  "modules": [
+{
+  "file": "a.out",
+  "systemPath": "a.out",
+  "loadAddress": "0x0040",
+  "uuid": "6AA9A4E2-6F28-2F33-377D-59FECE874C71-5B41261A"
+}
+  ]
+}
+  ]
+}
Index: lldb/test/API/commands/trace/intelpt-trace/trace_bad_image.json
===
--- /dev/null
+++ lldb/test/API/commands/trace/intelpt-trace/trace_bad_image.json
@@ -0,0 +1,31 @@
+{
+  "trace": {
+"type": "intel-pt",
+"pt_cpu": {
+  "vendor": "intel",
+  "family": 6,
+  "model": 79,
+  "stepping": 1
+}
+  },
+  "processes": [
+{
+  "pid": 1234,
+  "triple": "x86_64-*-linux",
+  "threads": [
+{
+  "tid": 3842849,
+  "traceFile": "3842849.trace"
+}
+  ],
+  "modules": [
+{
+  "file": "a.out",
+  "systemPath": "a.out",
+  "loadAddress": "0x00F0",
+  "uuid": "6AA9A4E2-6F28-2F33-377D-59FECE874C71-5B41261A"
+}
+  ]
+}
+  ]
+}
Index: lldb/test/API/commands/trace/intelpt-trace-multi-file/multi-file-no-ld.json
===
--- /dev/null
+++ lldb/test/API/commands/trace/intelpt-trace-multi-file/multi-file-no-ld.json
@@ -0,0 +1,43 @@
+{
+  "trace": {
+"type": "intel-pt",
+"pt_cpu": {
+  "vendor": "intel",
+  "family": 6,
+  "model": 79,
+  "stepping": 1
+}
+  },
+  "processes": [
+{
+  "pid": 815455,
+  "triple": "x86_64-*-linux",
+  "threads": [
+{
+  "tid": 815455,
+  "traceFile": "multi-file.trace"
+}
+  ],
+  "modules": [
+{
+  "file": "a.out",
+  "systemPath": "a.out",
+  "loadAddress": "0x0040",
+  "uuid": "D2414468-7112-B7C5-408D-FF07E30D5B17-A5BFD2C4"
+},
+{
+  "file": "libfoo.so",
+  "systemPath": "libfoo.so",
+  "loadAddress": "0x77bd9000",
+  "uuid": "B30FFEDA-8BB2-3D08-4580-C5937ED11E2B-21BE778C"
+},
+{
+  "file": "libbar.so",
+  "systemPath": "libbar.so",
+  "loadAddress": "0x779d7000",
+  "uuid": "6633B038-EA73-D1A6-FF9A-7D0C0EDF733D-95FEA2CC"
+}
+  ]
+}
+  ]
+}
Index: lldb/test/API/commands/trace/intelpt-trace-multi-file/main.cpp
==

Re: [Lldb-commits] Upcoming upgrade of LLVM buildbot

2020-10-27 Thread Galina Kistanova via lldb-commits

Hello Vitaly,

This should be fixed.

Please let me know if you still see the issue.

Thanks

Galina



On Tue, Oct 27, 2020 at 4:45 PM Vitaly Buka  wrote:

> It looks fixed. I haven't seen them in recent reports.
>
> On Tue, 27 Oct 2020 at 16:32, Vitaly Buka  wrote:
>
>> Any news regarding false-negatives?
>>
>> +Mitch Phillips 
>>
>> On Mon, 19 Oct 2020 at 22:07, Galina Kistanova 
>> wrote:
>>
>>> Thanks, Vitaly.
>>> Somebody is looking at this.
>>>
>>>
>>> On Mon, Oct 19, 2020 at 9:56 PM Vitaly Buka 
>>> wrote:
>>>
 it's not just staging, this build must be marked as failed
 http://lab.llvm.org:8011/#/builders/74/builds/122


 On Mon, 19 Oct 2020 at 11:50, Vitaly Buka 
 wrote:

> There is some issue, at least on staging.
> http://lab.llvm.org:8014/#/builders/89/builds/184 has multiple failed
> stages but marked as SUCCESS
>
>
> On Mon, 19 Oct 2020 at 11:43, Vitaly Buka 
> wrote:
>
>> Thanks!
>> Done.
>>
>> On Sat, 17 Oct 2020 at 12:45, Galina Kistanova 
>> wrote:
>>
>>> Thanks everyone for keeping your annotated builders in the staging
>>> area! Much appreciated.
>>>
>>> Please feel free to move all the green builders back to the
>>> production. It has a new AnnotatedCommand now.
>>>
>>> Thanks
>>>
>>> Galina
>>>
>>>
>>> On Thu, Oct 15, 2020 at 12:46 AM Vitaly Buka 
>>> wrote:
>>>
 Ok, I can switch them back to staging. However today's staging was
 frequently offline.


 On Wed, 14 Oct 2020 at 21:44, Galina Kistanova <
 gkistan...@gmail.com> wrote:

> Thanks everyone!
>
> I would like to keep the bots in the staging till Friday. And if
> everything is good, then apply the changes to the production and let 
> you
> move all the green bots back there.
>
> Thanks
>
> Galina
>
>
> On Tue, Oct 13, 2020 at 10:43 PM Vitaly Buka <
> vitalyb...@google.com> wrote:
>
>> They do on staging.
>> http://lab.llvm.org:8014/#/builders/sanitizer-windows
>> http://lab.llvm.org:8014/#/builders/clang-x64-windows-msvc
>>
>> Galina, when do you plan to push this to the primary server?
>> If it's a few days, I'd rather keep bots on staging to have
>> colors.
>>
>>
>>
>> On Tue, 13 Oct 2020 at 11:11, Reid Kleckner 
>> wrote:
>>
>>> FWIW, I don't see any issues with my two bots that use buildbot
>>> annotated commands:
>>> http://lab.llvm.org:8011/#/builders/sanitizer-windows
>>> http://lab.llvm.org:8011/#/builders/clang-x64-windows-msvc
>>> The individual steps don't highlight as green or red, but that's
>>> OK for now.
>>>
>>> On Mon, Oct 12, 2020 at 7:19 PM Galina Kistanova <
>>> gkistan...@gmail.com> wrote:
>>>
 We have a better version of AnnotatedCommand on the staging. It
 should be a functional equivalent of the old one.
 We need to stress test it well before moving to the production
 build bot.

 For that we need all sanitizer + other bots which use the
 AnnotatedCommand directly or indirectly moved temporarily to the 
 staging.

 Please let me know when that could be arranged.

 Thanks

 Galina

 On Mon, Oct 12, 2020 at 11:39 AM Reid Kleckner 
 wrote:

> On Wed, Oct 7, 2020 at 4:32 PM Galina Kistanova via
> lldb-commits  wrote:
>
>> They are online now -
>> http://lab.llvm.org:8011/#/waterfall?tags=sanitizer
>>
>> AnnotatedCommand has severe design conflict with the new
>> buildbot.
>> We have changed it to be safe and still do something useful,
>> but it will need more love and care.
>>
>> Please let me know if you have some spare time to work on
>> porting AnnotatedCommand.
>>
>
> That's unfortunate, it would've been good to know that
> earlier. I and another team member have spent a fair amount of 
> time porting
> things to use more AnnotatedCommand steps, because it gives us the
> flexibility to test steps locally and make changes to the steps 
> without
> restarting the buildbot master. IMO that is the Right Way to 
> define steps:
> a script that you can run locally on a machine that satisfies the 
> OS and
> dep requirements of the script.
>
> I am restarting the two bots that I a

[Lldb-commits] [PATCH] D90276: [lldb/utils] Add the lldb-env tool

2020-10-27 Thread Vedant Kumar via Phabricator via lldb-commits

vsk created this revision.
vsk added reviewers: JDevlieghere, teemperor, mgorny.
Herald added a project: LLDB.
vsk requested review of this revision.

Introduce lldb-env, a tool that prints out the environment variables
needed to launch lldb.

Usually, no environment variables need to be set to launch lldb: in
these cases lldb-env prints nothing.

In a sanitized build, lldb-env prints out any mandatory `DYLD_*` options
needed to set up sanitizer interceptors early. The Darwin-specific logic
is just a starting point. The end goal would be to support launching
lldb on any platform via `export $(path/to/lldb-env); path/to/lldb`. The
current logic is taken/moved from test/API/lit.cfg. As a follow-up, we
could have lldb-dotest use lldb-env as well.

Testing: check-lldb with LLVM_USE_SANITIZER='Address'


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90276

Files:
  lldb/test/API/lit.cfg.py
  lldb/test/CMakeLists.txt
  lldb/utils/lldb-dotest/CMakeLists.txt
  lldb/utils/lldb-dotest/lldb-env.in

Index: lldb/utils/lldb-dotest/lldb-env.in
===
--- /dev/null
+++ lldb/utils/lldb-dotest/lldb-env.in
@@ -0,0 +1,37 @@
+#!@Python3_EXECUTABLE@
+import os
+import platform
+import subprocess
+import sys
+
+llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
+compiler = '@CMAKE_CXX_COMPILER@'
+
+def get_dyld_option_for_sanitizer(name):
+# FIXME: Get the host OS from cmake, instead of assuming macOS.
+resource_dir = subprocess.check_output(
+[compiler, '-print-resource-dir']).decode('utf-8').strip()
+rt_path = os.path.join(resource_dir, 'lib', 'darwin',
+   'libclang_rt.{0}_osx_dynamic.dylib'.format(name))
+return 'DYLD_INSERT_LIBRARIES={0}'.format(rt_path)
+
+if __name__ == '__main__':
+env_vars = []
+
+asan_enabled = 'Address' in llvm_use_sanitizer
+tsan_enabled = 'Thread' in llvm_use_sanitizer
+
+if asan_enabled:
+env_vars.append("ASAN_OPTIONS='detect_stack_use_after_return=1'")
+
+if platform.system() == 'Darwin':
+if asan_enabled:
+env_vars.append(get_dyld_option_for_sanitizer('asan'))
+
+if tsan_enabled:
+env_vars.append(get_dyld_option_for_sanitizer('tsan'))
+
+if len(env_vars):
+print('\n'.join(env_vars))
+
+sys.exit(0)
Index: lldb/utils/lldb-dotest/CMakeLists.txt
===
--- lldb/utils/lldb-dotest/CMakeLists.txt
+++ lldb/utils/lldb-dotest/CMakeLists.txt
@@ -1,3 +1,7 @@
+# Make lldb-env a custom target.
+add_custom_target(lldb-env)
+set_target_properties(lldb-env PROPERTIES FOLDER "lldb utils")
+
 # Make lldb-dotest a custom target.
 add_custom_target(lldb-dotest)
 add_dependencies(lldb-dotest lldb-test-deps)
@@ -66,6 +70,10 @@
   lldb-dotest.in
   ${config_runtime_output_dir}/lldb-dotest @ONLY
 )
+configure_file(
+  lldb-env.in
+  ${config_runtime_output_dir}/lldb-env @ONLY
+)
   endforeach()
 elseif(NOT "${CMAKE_CFG_INTDIR}" STREQUAL ".")
   foreach(LLVM_BUILD_MODE ${CMAKE_CONFIGURATION_TYPES})
@@ -87,6 +95,10 @@
   lldb-dotest.in
   ${LLDB_DOTEST_DIR}/lldb-dotest
   )
+configure_file(
+  lldb-env.in
+  ${LLDB_DOTEST_DIR}/lldb-env
+  )
   endforeach()
 else()
   set(LLDB_DOTEST_ARGS_CONFIGURED "${LLDB_DOTEST_ARGS}")
@@ -106,4 +118,8 @@
 lldb-dotest.in
 ${LLVM_RUNTIME_OUTPUT_INTDIR}/lldb-dotest
 )
+  configure_file(
+lldb-env.in
+${LLVM_RUNTIME_OUTPUT_INTDIR}/lldb-env
+)
 endif()
Index: lldb/test/CMakeLists.txt
===
--- lldb/test/CMakeLists.txt
+++ lldb/test/CMakeLists.txt
@@ -69,6 +69,10 @@
   add_lldb_test_dependency(lldb-framework)
 endif()
 
+if(TARGET lldb-env)
+  add_lldb_test_dependency(lldb-env)
+endif()
+
 # Add dependencies that are not exported targets when building standalone.
 if(NOT LLDB_BUILT_STANDALONE)
   add_lldb_test_dependency(
Index: lldb/test/API/lit.cfg.py
===
--- lldb/test/API/lit.cfg.py
+++ lldb/test/API/lit.cfg.py
@@ -33,13 +33,6 @@
 raise OSError(errno.ENOTDIR, "%s is not a directory"%path)
 
 
-def find_sanitizer_runtime(name):
-  resource_dir = subprocess.check_output(
-  [config.cmake_cxx_compiler,
-   '-print-resource-dir']).decode('utf-8').strip()
-  return os.path.join(resource_dir, 'lib', 'darwin', name)
-
-
 def find_shlibpath_var():
   if platform.system() in ['Linux', 'FreeBSD', 'NetBSD', 'SunOS']:
 yield 'LD_LIBRARY_PATH'
@@ -102,16 +95,13 @@
 shutil.rmtree(path)
 
 if is_configured('llvm_use_sanitizer'):
-  if 'Address' in config.llvm_use_sanitizer:
-config.environment['ASAN_OPTIONS'] = 'detect_stack_use_after_return=1'
-if 'Darwin' in config.host_os and 'x86' in config.host_triple:
-  config.environment['DYLD_INSERT_LIBRARIES'] = find_sanitizer_runtime(
-  'libclang_rt.asan_os

[Lldb-commits] [PATCH] D90276: [lldb/utils] Add the lldb-env tool

2020-10-27 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added a comment.

Can you explain the added value of the tool a bit more. I can see how it's nice 
to be able to run `export $(lldb-env); path/to/lldb` but I wonder how often 
you'd end up doing that. When I invoke lldb directly, it's mostly to debug a 
test case, in which case I'd need to run lldb under lldb and set the 
environment variables myself. It also means we have to configure an additional 
file which goes against my effort of making the lit.site.cfg file self 
contained (to be able to run the test suite against a different toolchain).

FWIW my plan was to deprecate `lldb-dotest` at some in favor of either using 
`llvm-lit` directly or by wrapping it. I hate maintaining the code in 
`lldb-dotest/CMakeLists.txt` because I always break the standalone build when I 
forget to add a variable.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90276/new/

https://reviews.llvm.org/D90276

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D90276: [lldb/utils] Add the lldb-env tool

2020-10-27 Thread Vedant Kumar via Phabricator via lldb-commits

vsk added a comment.

In D90276#2357978 , @JDevlieghere 
wrote:

> Can you explain the added value of the tool a bit more. I can see how it's 
> nice to be able to run `export $(lldb-env); path/to/lldb` but I wonder how 
> often you'd end up doing that. When I invoke lldb directly, it's mostly to 
> debug a test case, in which case I'd need to run lldb under lldb and set the 
> environment variables myself. It also means we have to configure an 
> additional file which goes against my effort of making the lit.site.cfg file 
> self contained (to be able to run the test suite against a different 
> toolchain).

The specific workflow I'm interested in is invoking lldb on a test program, 
then importing a script to drive a debug session in CI. Having the settings I 
need defined in one place is nice, this means I can avoid duplicating logic 
from a lit.cfg in my workflow. It also prevents the settings from getting out 
of sync (looking at this -- 
https://github.com/apple/llvm-project/blob/swift/main/lldb/test/Shell/lit.cfg.py#L45).

Re: making the lit.site.cfg self-contained, IIUC the situation is that there 
are a couple places where we shell out via `subprocess`, but that you'd like to 
get rid of these? I wonder whether we could bundle up the necessary scripts 
along with lit.site.cfg instead.

> FWIW my plan was to deprecate `lldb-dotest` at some in favor of either using 
> `llvm-lit` directly or by wrapping it. I hate maintaining the code in 
> `lldb-dotest/CMakeLists.txt` because I always break the standalone build when 
> I forget to add a variable.

My intention was to make sure we get an lldb-env everywhere we already expect a 
lldb-dotest. If that's not required, I'd be fine with moving the new tool 
elsewhere.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90276/new/

https://reviews.llvm.org/D90276

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D90276: [lldb/utils] Add the lldb-env tool

2020-10-27 Thread Jonas Devlieghere via Phabricator via lldb-commits

JDevlieghere added a comment.

In D90276#2358016 , @vsk wrote:

> In D90276#2357978 , @JDevlieghere 
> wrote:
>
>> Can you explain the added value of the tool a bit more. I can see how it's 
>> nice to be able to run `export $(lldb-env); path/to/lldb` but I wonder how 
>> often you'd end up doing that. When I invoke lldb directly, it's mostly to 
>> debug a test case, in which case I'd need to run lldb under lldb and set the 
>> environment variables myself. It also means we have to configure an 
>> additional file which goes against my effort of making the lit.site.cfg file 
>> self contained (to be able to run the test suite against a different 
>> toolchain).
>
> The specific workflow I'm interested in is invoking lldb on a test program, 
> then importing a script to drive a debug session in CI. Having the settings I 
> need defined in one place is nice, this means I can avoid duplicating logic 
> from a lit.cfg in my workflow. It also prevents the settings from getting out 
> of sync (looking at this -- 
> https://github.com/apple/llvm-project/blob/swift/main/lldb/test/Shell/lit.cfg.py#L45).

Another way to solve that would be to move it up to the top level lit 
configuration rather than doing it once for the shell tests and once for the 
API tests.

> Re: making the lit.site.cfg self-contained, IIUC the situation is that there 
> are a couple places where we shell out via `subprocess`, but that you'd like 
> to get rid of these? I wonder whether we could bundle up the necessary 
> scripts along with lit.site.cfg instead.

My remark was not so much about the need for another tool but rather the need 
to configure it. Right now I can hand-write a `lit.site.cfg.py`, omit a bunch 
of values, and point lit to it. With this tool I'd need to also configure it 
(i.e. replacing `@LLVM_USE_SANITIZER@` and `@CMAKE_CXX_COMPILER@`. I wonder if 
there's any way to make `lldb-dotest` and this tool load the `lit.site.cfg.py` 
and use the variables that we put in the config there.

>> FWIW my plan was to deprecate `lldb-dotest` at some in favor of either using 
>> `llvm-lit` directly or by wrapping it. I hate maintaining the code in 
>> `lldb-dotest/CMakeLists.txt` because I always break the standalone build 
>> when I forget to add a variable.
>
> My intention was to make sure we get an lldb-env everywhere we already expect 
> a lldb-dotest. If that's not required, I'd be fine with moving the new tool 
> elsewhere.

I think that if we were to move this under `lldb/test` we might get that for 
free if we use the same `@`-variable names as the `lit.site.cfg.py`. I think 
that'd be a good idea regardless (and also most certainly a different patch).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90276/new/

https://reviews.llvm.org/D90276

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D90102: [lldb] [Process/FreeBSDRemote] Enable watchpoint support

[Lldb-commits] [PATCH] D90102: [lldb] [Process/FreeBSDRemote] Enable watchpoint support

[Lldb-commits] [PATCH] D87172: Check if debug line sequences are starting after the first code segment

[Lldb-commits] [PATCH] D90102: [lldb] [Process/FreeBSDRemote] Enable watchpoint support

[Lldb-commits] [lldb] 1f933ff - [lldb][NFC] Rewrite TestQuoting

[Lldb-commits] [PATCH] D89334: [lldb] Support Python imports relative the to the current file being sourced

[Lldb-commits] [PATCH] D90102: [lldb] [Process/FreeBSDRemote] Enable watchpoint support

[Lldb-commits] [lldb] f8a3b9b - [lldb] Correct vFile:pread/pwrite packet docs

[Lldb-commits] [PATCH] D89383: [lldb] Correct vFile:pread/pwrite packet docs

[Lldb-commits] [PATCH] D89383: [lldb] Correct vFile:pread/pwrite packet docs

[Lldb-commits] [PATCH] D90225: [lldb] Correct --help output for qemu rootfs script

[Lldb-commits] [PATCH] D90102: [lldb] [Process/FreeBSDRemote] Enable watchpoint support

[Lldb-commits] [lldb] 8e7ea99 - [lldb] [Process/FreeBSDRemote] Enable watchpoint support

[Lldb-commits] [lldb] 4ba8ea4 - [lldb] [Process/FreeBSD] Fix missing namespace qualifier

[Lldb-commits] [lldb] d43c70a - [lldb] Add llvm-pdbutil to lldb test dependencies

[Lldb-commits] [lldb] 45c3fc9 - [lldb][NFC] Make GetResumeCountForLaunchInfo return an unsigned.

[Lldb-commits] [PATCH] D89334: [lldb] Support Python imports relative the to the current file being sourced

[Lldb-commits] [PATCH] D89334: [lldb] Support Python imports relative the to the current file being sourced

[Lldb-commits] [lldb] 00bb397 - [lldb] Support Python imports relative the to the current file being sourced

[Lldb-commits] [PATCH] D89283: [trace][intel-pt] Implement the basic decoding functionality

[Lldb-commits] [PATCH] D88483: Add possibility to get module from SBType

[Lldb-commits] [PATCH] D88483: Add possibility to get module from SBType

Re: [Lldb-commits] Upcoming upgrade of LLVM buildbot

Re: [Lldb-commits] Upcoming upgrade of LLVM buildbot

[Lldb-commits] [PATCH] D89283: [trace][intel-pt] Implement the basic decoding functionality

[Lldb-commits] [PATCH] D89283: [trace][intel-pt] Implement the basic decoding functionality

Re: [Lldb-commits] Upcoming upgrade of LLVM buildbot

[Lldb-commits] [PATCH] D90276: [lldb/utils] Add the lldb-env tool

[Lldb-commits] [PATCH] D90276: [lldb/utils] Add the lldb-env tool

[Lldb-commits] [PATCH] D90276: [lldb/utils] Add the lldb-env tool

[Lldb-commits] [PATCH] D90276: [lldb/utils] Add the lldb-env tool

31 matches

Site Navigation

Mail list logo

Footer information