[Lldb-commits] [lldb] 3d27a99 - [LLDB] Remove AArch64/Linux xfail decorator from TestGuiBasicDebug

[Muhammad Omair Javaid via lldb-commits]

Author: Muhammad Omair Javaid
Date: 2020-10-01T10:20:22+05:00
New Revision: 3d27a99b2ed24e1951483cf13357ec188ad44bb0

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

LOG: [LLDB] Remove AArch64/Linux xfail decorator from TestGuiBasicDebug

This test now passes on AArch64/Linux after following change by Jonas:
d689570d7dcb16ee241676e22324dc456837eb23

Added: 


Modified: 
lldb/test/API/commands/gui/basicdebug/TestGuiBasicDebug.py

Removed: 




diff  --git a/lldb/test/API/commands/gui/basicdebug/TestGuiBasicDebug.py 
b/lldb/test/API/commands/gui/basicdebug/TestGuiBasicDebug.py
index 81067bf776e3..9deb700da39c 100644
--- a/lldb/test/API/commands/gui/basicdebug/TestGuiBasicDebug.py
+++ b/lldb/test/API/commands/gui/basicdebug/TestGuiBasicDebug.py
@@ -15,7 +15,6 @@ class TestGuiBasicDebugCommandTest(PExpectTest):
 # under ASAN on a loaded machine..
 @skipIfAsan
 @skipIfCursesSupportMissing
-@expectedFailureAll(archs=["aarch64"], oslist=["linux"])
 def test_gui(self):
 self.build()
 



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

[Lldb-commits] [PATCH] D88632: A handful of fixes to lldb's "scan the local filesystem for kexts & kernels" feature

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda created this revision.
jasonmolenda added a project: LLDB.
Herald added subscribers: lldb-commits, JDevlieghere.
jasonmolenda requested review of this revision.

This started out with one small idea I had and then got a bit of PatchCreep 
while I was digging into  a subsystem I haven't touched in a year or two.  The 
patch is all isolated to darwin kernel debugging, it doesn't modify anything 
outside of that.  The things I changed here:

1. When looking on the local filesystem for a kernel binary + dSYM pair, if 
that fails, look through any dSYMs that we saw alone without a binary, and load 
those as a binary+dSYM pair all by itself.  It's not ideal, but it will mostly 
work.

2. Remove the 'platform.plugin.darwin-kernel.search-locally-for-kexts' setting. 
 I originally added this setting when I first added the local filesystem scan 
for kexts/kernels, fearing that people would ask for a way to disable it.  No 
one has ever asked.  I thought of making the setting a no-op and documenting it 
as obsoleted, but eventually it'll have to be removed and someone will get an 
error in their .lldbinit file if they're still using it.  Might as well make 
that now.

3. Change plugin.dynamic-loader.darwin-kernel.load-kexts so that it doesn't 
disable local kernel binary scanning.  It was a nonobvious interaction, I see 
kernel developers trip over this occasionally.

4. Split up PlatformDarwinKernel::GetSharedModule into GetSharedModuleKext and 
GetSharedModuleKernel.  This method was unnecessarily large and the blocks of 
code had no interaction with each other; splitting it out makes it easier to 
read and modify.

5. I keep track of possible kernel .dSYM.yaa (a file archive format) files that 
I come across during the scan, but I'm only reporting it in the statistics for 
now, I don't think I want to pay the cost of expanding these to see if they're 
a match.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D88632

Files:
  lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
  lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp
  lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
  lldb/source/Plugins/Platform/MacOSX/PlatformMacOSXProperties.td

Index: lldb/source/Plugins/Platform/MacOSX/PlatformMacOSXProperties.td
===
--- lldb/source/Plugins/Platform/MacOSX/PlatformMacOSXProperties.td
+++ lldb/source/Plugins/Platform/MacOSX/PlatformMacOSXProperties.td
@@ -1,10 +1,6 @@
 include "../../../../include/lldb/Core/PropertiesBase.td"
 
 let Definition = "platformdarwinkernel" in {
-  def SearchForKexts: Property<"search-locally-for-kexts", "Boolean">,
-Global,
-DefaultTrue,
-Desc<"Automatically search for kexts on the local system when doing kernel debugging.">;
   def KextDirectories: Property<"kext-directories", "FileSpecList">,
 DefaultStringValue<"">,
 Desc<"Directories/KDKs to search for kexts in when starting a kernel debug session.">;
Index: lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
===
--- lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
+++ lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.h
@@ -126,7 +126,30 @@
 
   // Returns true if there is a .dSYM bundle next to the kernel
   static bool
-  KernelHasdSYMSibling(const lldb_private::FileSpec _bundle_filepath);
+  KernelHasdSYMSibling(const lldb_private::FileSpec _filepath);
+
+  // Returns true if there is a .dSYM bundle with NO kernel binary next to it
+  static bool KerneldSYMHasNoSiblingBinary(
+  const lldb_private::FileSpec _dsym_filepath);
+
+  // Given a dsym_bundle argument ('.../foo.dSYM'), return a FileSpec
+  // with the binary inside it ('.../foo.dSYM/Contents/Resources/DWARF/foo').
+  // A dSYM bundle may have multiple DWARF binaries in them, so a vector
+  // of matches is returned.
+  static std::vector
+  GetDWARFBinaryInDSYMBundle(lldb_private::FileSpec dsym_bundle);
+
+  lldb_private::Status
+  GetSharedModuleKext(const lldb_private::ModuleSpec _spec,
+  lldb_private::Process *process, lldb::ModuleSP _sp,
+  const lldb_private::FileSpecList *module_search_paths_ptr,
+  lldb::ModuleSP *old_module_sp_ptr, bool *did_create_ptr);
+
+  lldb_private::Status GetSharedModuleKernel(
+  const lldb_private::ModuleSpec _spec,
+  lldb_private::Process *process, lldb::ModuleSP _sp,
+  const lldb_private::FileSpecList *module_search_paths_ptr,
+  lldb::ModuleSP *old_module_sp_ptr, bool *did_create_ptr);
 
   lldb_private::Status
   ExamineKextForMatchingUUID(const lldb_private::FileSpec _bundle_path,
@@ -170,6 +193,13 @@
   // on local
   // filesystem, with
   

[Lldb-commits] [PATCH] D86670: [intel-pt] Add a basic implementation of the dump command

[Greg Clayton via Phabricator via lldb-commits]

clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.

See inlined comments.




Comment at: lldb/include/lldb/Target/Target.h:32
 #include "lldb/Target/ThreadSpec.h"
+#include "lldb/Target/Trace.h"
 #include "lldb/Utility/ArchSpec.h"

You don't need this as the only "Trace" in this file is the "TraceSP" which is 
a forward declaration. You will need to add it to the Target.cpp file though.



Comment at: lldb/include/lldb/Target/Target.h:1261
 /// This holds the python callback object.
-StructuredData::GenericSP m_implementation_sp; 
+StructuredData::GenericSP m_implementation_sp;
 

remove whitespace only changes



Comment at: lldb/include/lldb/Target/Target.h:1381
 /// classes make the SB interface thread safe
-  /// When the private state thread calls SB API's - usually because it is 
+  /// When the private state thread calls SB API's - usually because it is
   /// running OS plugin or Python ThreadPlan code - it should not block on the

remove whitespace only changes



Comment at: lldb/include/lldb/Target/Target.h:1384
   /// API mutex that is held by the code that kicked off the sequence of events
-  /// that led us to run the code.  We hand out this mutex instead when we 
+  /// that led us to run the code.  We hand out this mutex instead when we
   /// detect that code is running on the private state thread.

remove whitespace only changes



Comment at: lldb/source/Commands/CommandObjectTrace.cpp:182
+interpreter, "trace dump",
+"Dump the loaded processor trace data from the current target.",
+"trace dump"),

s/from/in/ in the text?



Comment at: lldb/source/Commands/CommandObjectTrace.cpp:183
+"Dump the loaded processor trace data from the current target.",
+"trace dump"),
 m_options() {}

add the "eCommandRequiresTarget" at the end here to indicate this command 
requires a valid target. It will then never even get to the DoExecute(...) 
function if there isn't a valid target.



Comment at: lldb/source/Commands/CommandObjectTrace.cpp:193
 Status error;
-// TODO: fill in the dumping code here!
+Target  = GetSelectedOrDummyTarget();
+target.DumpTrace(result.GetOutputStream(), m_options.m_dump_options);

If we add eCommandRequiresTarget to the constructor, then we can just call 
GetSelectedTarget(). The dummy target won't do us any good. This also means we 
don't have to add a test for the target being valid for "trace dump" since the 
eCommandRequiresTarget is already tested!



Comment at: lldb/source/Commands/Options.td:1191-1192
 Desc<"Show verbose trace information.">;
+  def trace_dump_thread_id : Option<"thread-id", "t">, Group<1>,
+Arg<"ThreadID">, Desc<"The thread id to dump trace information of.">;
 }

Can or should this be able to be specified more than once?



Comment at: lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp:141-143
+  if (options.verbose) {
+DumpJSONSettings(s);
+  }

remove braces for single line if statement.



Comment at: lldb/test/API/commands/trace/TestTraceDump.py:18
+def testDumpTrace(self):
+self.expect("trace dump", substrs=["error: no trace data in this 
target"])
+

This might change to "invalid target" if we use eCommandRequiresTarget in the 
command object. If so, we will need to create a target with no trace data and 
still test that we can get this error.



Comment at: lldb/test/API/commands/trace/TestTraceDump.py:42
+
+self.expect("trace dump -t 21 --thread-id 22", substrs=["Trace files"],
+  patterns=["pid: '2', tid: '21', trace file: 
.*/test/API/commands/trace/intelpt-trace/3842849.trace",

I would either use all "-t" or all "--thread-id" here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86670

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

[Lldb-commits] [lldb] d689570 - [lldb] Make TestGuiBasicDebug more lenient

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2020-09-30T17:06:47-07:00
New Revision: d689570d7dcb16ee241676e22324dc456837eb23

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

LOG: [lldb] Make TestGuiBasicDebug more lenient

Matt's change to the register allocator in 89baeaef2fa9 changed where we
end up after the `finish`. Before we'd end up on line 4.

* thread #1, queue = 'com.apple.main-thread', stop reason = step out
Return value: (int) $0 = 1
frame #0: 0x00013f7d a.out`main(argc=1, argv=0x7ffeefbff630) at 
main.c:4:3
   1extern int func();
   2
   3int main(int argc, char **argv) {
-> 4  func(); // Break here
   5  func(); // Second
   6  return 0;
   7}

Now, we end up on line 5.

* thread #1, queue = 'com.apple.main-thread', stop reason = step out
Return value: (int) $0 = 1

frame #0: 0x00013f8d a.out`main(argc=1, argv=0x7ffeefbff630) at 
main.c:5:3
   2
   3int main(int argc, char **argv) {
   4  func(); // Break here
-> 5  func(); // Second
   6  return 0;
   7}

Given that this is not expected stable to be stable I've made the test a
bit more lenient to accept both scenarios.

Added: 


Modified: 
lldb/test/API/commands/gui/basicdebug/TestGuiBasicDebug.py

Removed: 




diff  --git a/lldb/test/API/commands/gui/basicdebug/TestGuiBasicDebug.py 
b/lldb/test/API/commands/gui/basicdebug/TestGuiBasicDebug.py
index ed5daf57a4441..81067bf776e39 100644
--- a/lldb/test/API/commands/gui/basicdebug/TestGuiBasicDebug.py
+++ b/lldb/test/API/commands/gui/basicdebug/TestGuiBasicDebug.py
@@ -37,11 +37,11 @@ def test_gui(self):
 self.child.send("d") # down
 self.child.expect_exact("return 1; // In function")
 self.child.send("f") # finish
-self.child.expect("func\(\); // Break here[^\r\n]+<<< Thread 1: step 
out")
+self.child.expect("<<< Thread 1: step out")
 self.child.send("s") # move onto the second one
-self.child.expect("func\(\); // Second[^\r\n]+<<< Thread 1: step in")
+self.child.expect("<<< Thread 1: step in")
 self.child.send("n") # step over
-self.child.expect("return 0;[^\r\n]+<<< Thread 1: step over")
+self.child.expect("<<< Thread 1: step over")
 
 # Press escape to quit the gui
 self.child.send(escape_key)



___
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

[Greg Clayton via Phabricator via lldb-commits]

clayborg added inline comments.



Comment at: lldb/unittests/SymbolFile/DWARF/SymbolFileDWARFTests.cpp:369
+  EXPECT_EQ(section_sp->GetType(), eSectionTypeCode);
+}

labath wrote:
> clayborg wrote:
> > I would rather deal with an  C++ unit test any day. Trying to track down 
> > what set of convoluted command line commands reproduce some lit test is 
> > quite annoying and takes me a lot more time to debug. I think this test is 
> > targeted and tests what is needed. I would vote to keep this one over 
> > converting to a text dump test. My main reasoning is that it isn't possible 
> > to re-create a compilable test case that will survive any compiler that it 
> > used (past, present and future), and all symbol resolution is done bone 
> > using this call in all cases. When something goes wrong, very easy to 
> > compile the binary and debug.
> If we put this up for a vote, I think you'd be in the minority. :)
> 
> I'm not sure what you find hard about reproducing a lit test -- the commands 
> to do that get printed as a part of the test. And most of the time you don't 
> need to run all the command to reproduce it -- running the last one suffices 
> as the intermediate files are left over from the previous test run. I 
> consider the leftover temporaries as one of the best aspects of this method. 
> In this case, I could for example run llvm-dwarfdump on the intermediate 
> object file to better understand the input that lldb gets.
> 
> Note that I am not advocating changing the test input to c++ source. I think 
> the yaml is just fine (if I was writing it, I would probably have made that 
> an assembler file). I just meant changing the test method by prefixing the 
> yaml with something like:
> ```
> # RUN: yaml2obj %s > %t
> # RUN: %lldb %t -b -o "image lookup -f main.cpp -l 2" | FileCheck %s
> # CHECK: LineEntry: {{.*}}main.cpp:2 # or something like that
> ```
> If we put this up for a vote, I think you'd be in the minority. :)
> 
> I'm not sure what you find hard about reproducing a lit test -- the commands 
> to do that get printed as a part of the test. And most of the time you don't 
> need to run all the command to reproduce it -- running the last one suffices 
> as the intermediate files are left over from the previous test run. I 
> consider the leftover temporaries as one of the best aspects of this method. 
> In this case, I could for example run llvm-dwarfdump on the intermediate 
> object file to better understand the input that lldb gets.
> 
> Note that I am not advocating changing the test input to c++ source. I think 
> the yaml is just fine (if I was writing it, I would probably have made that 
> an assembler file). I just meant changing the test method by prefixing the 
> yaml with something like:
> ```
> # RUN: yaml2obj %s > %t
> # RUN: %lldb %t -b -o "image lookup -f main.cpp -l 2" | FileCheck %s
> # CHECK: LineEntry: {{.*}}main.cpp:2 # or something like that
> ```

If it is that easy, then sounds good. I was thinking you were asking him to add 
new functionality for dumping something.


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] D87868: [RFC] When calling the process mmap try to call all found instead of just the first one

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

In D87868#2303398 , @labath wrote:

> A completely different approach would be to avoid the mmap function 
> completely, and go for the mmap syscall instead.
>
> That is, instead of setting up registers to fake call to mmap and doing a 
> run-to entry point breakpoint, we could set them up to fake a syscall, and 
> then do an instruction-step over a syscall instruction (which we could place 
> at the entry point, or find a suitable one in the binary).
>
> The advantage of that would be that this would work not only in this 
> (sanitizer) case, but also in all other cases where an mmap symbol is not 
> present/functional/unambiguous:
>
> - a bare-bone statically linked binary need not contain an mmap function
> - very early in the program startup (before relocations are applied) it may 
> not be safe to call the global mmap
> - mmap may be buggy (libc debugging?)

That is possible, though how do we figure out the syscall enumeration for the 
mmap syscall reliably for a given system? And if we are remote debugging? Seems 
like we are signing up for architecture specific syscalls on every different 
architecture. Not sure I would go that route, but I am open to seeing a 
solution before passing judgement.

> Note that this would not need to be implemented in the lldb client. This sort 
> of thing would be natural to implement in lldb server in response to the `_M` 
> packet. There it would be easy to encode the abi details needed to issue a 
> syscall. The client already prefers this packet, and the existing code could 
> remain as a fallback for platforms not implementing it.

There is no code currently that does any run control down inside of lldb-server 
and I would like to keep it that way if possible. debugserver can do it only 
because we have the task port to the program we are debugging and we can call a 
function in the debugserver process that does the memory allocation in the 
debug process. Having this done in lldb-server would require lldb-server to 
perform run control by changing register values, running the syscall, stopping 
at a breakpoint to after the syscall has run, removing that breakpoint only if 
it didn't exist already. Seems like a lot of dangerous flow control that we 
won't be able to see if anything goes wrong. Right now if we are doing it all 
through the GDB remote protocol, we can see exactly how things go wrong in the 
packet log, but now it would be a mystery if things go wrong.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87868

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

[Lldb-commits] [PATCH] D88266: Check that the "StructuredData Plugin weak pointer" is good before trying to turn it into a shared pointer

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

Agreed, must call weak_ptr.lock().


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88266

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

Re: [Lldb-commits] [lldb] 1b1d981 - Revert "Revert "Add the ability to write target stop-hooks using the ScriptInterpreter.""

[Pavel Labath via lldb-commits]

On 30/09/2020 20:45, Jim Ingham wrote:
> I also used to get e-mails when a test failed and I was on the changes list.  
> But I haven’t gotten any failure e-mails.  Does that only happen for some of 
> the bots (or has that stopped working) or should I look to my filters?
> 
> Jim
> 

You didn't get an email when the patch was committed, because the test
happened to pass the first time around and only fail in some of the
later builds. That's the problem with flaky tests -- whenever they fail
(flake) a random person gets a breakage email for their unrelated change.

As the test flaps on and off nondeterministically, I very much doubt
this is a problem with the incremental build. E.g. the only change in
build http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/18360
was a change to the gn build files, which is a noop for regular cmake
build. Both builds before it and after it were green.

Though it's possible, I would be surprised if this problem is limited to
linux systems -- a more likely explanation is that the linux buildbots
have a much higher throughput (lldb-x86_64-debian clocks 70 builds per
day vs. 13 builds/day for lldb-cmake on green dragon), and so flaky
tests get noticed sooner there.

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

[Lldb-commits] [PATCH] D88266: Check that the "StructuredData Plugin weak pointer" is good before trying to turn it into a shared pointer

[Jim Ingham via Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGafaeb6af79a4: Fix crash in 
SBStructuredData::GetDescription() when theres no… (authored by jingham).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88266

Files:
  lldb/include/lldb/Core/StructuredDataImpl.h
  lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py


Index: lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
===
--- lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
+++ lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
@@ -35,6 +35,13 @@
 # Tests for invalid data type
 self.invalid_struct_test(example)
 
+# Test that GetDescription works:
+s.Clear()
+error = example.GetDescription(s)
+self.assertTrue(error.Success(), "GetDescription works")
+if not "key_float" in s.GetData():
+self.fail("FAILED: could not find key_float in description output")
+
 dict_struct = lldb.SBStructuredData()
 dict_struct = example.GetValueForKey("key_dict")
 
Index: lldb/include/lldb/Core/StructuredDataImpl.h
===
--- lldb/include/lldb/Core/StructuredDataImpl.h
+++ lldb/include/lldb/Core/StructuredDataImpl.h
@@ -68,14 +68,18 @@
   return error;
 }
 
-// Grab the plugin.
-auto plugin_sp = lldb::StructuredDataPluginSP(m_plugin_wp);
+// Grab the plugin
+lldb::StructuredDataPluginSP plugin_sp = m_plugin_wp.lock();
+
+// If there's no plugin, call underlying data's dump method:
 if (!plugin_sp) {
-  error.SetErrorString("Cannot pretty print structured data: "
-   "plugin doesn't exist.");
+  if (!m_data_sp) {
+error.SetErrorString("No data to describe.");
+return error;
+  }
+  m_data_sp->Dump(stream, true);
   return error;
 }
-
 // Get the data's description.
 return plugin_sp->GetDescription(m_data_sp, stream);
   }


Index: lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
===
--- lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
+++ lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
@@ -35,6 +35,13 @@
 # Tests for invalid data type
 self.invalid_struct_test(example)
 
+# Test that GetDescription works:
+s.Clear()
+error = example.GetDescription(s)
+self.assertTrue(error.Success(), "GetDescription works")
+if not "key_float" in s.GetData():
+self.fail("FAILED: could not find key_float in description output")
+
 dict_struct = lldb.SBStructuredData()
 dict_struct = example.GetValueForKey("key_dict")
 
Index: lldb/include/lldb/Core/StructuredDataImpl.h
===
--- lldb/include/lldb/Core/StructuredDataImpl.h
+++ lldb/include/lldb/Core/StructuredDataImpl.h
@@ -68,14 +68,18 @@
   return error;
 }
 
-// Grab the plugin.
-auto plugin_sp = lldb::StructuredDataPluginSP(m_plugin_wp);
+// Grab the plugin
+lldb::StructuredDataPluginSP plugin_sp = m_plugin_wp.lock();
+
+// If there's no plugin, call underlying data's dump method:
 if (!plugin_sp) {
-  error.SetErrorString("Cannot pretty print structured data: "
-   "plugin doesn't exist.");
+  if (!m_data_sp) {
+error.SetErrorString("No data to describe.");
+return error;
+  }
+  m_data_sp->Dump(stream, true);
   return error;
 }
-
 // Get the data's description.
 return plugin_sp->GetDescription(m_data_sp, stream);
   }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] afaeb6a - Fix crash in SBStructuredData::GetDescription() when there's no StructuredDataPlugin.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-09-30T11:48:54-07:00
New Revision: afaeb6af79a4278249ef9114755e5685d0b35984

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

LOG: Fix crash in SBStructuredData::GetDescription() when there's no 
StructuredDataPlugin.

Also, use the StructuredData::Dump method to print the StructuredData if there
is no plugin, rather than just returning an error.

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

Added: 


Modified: 
lldb/include/lldb/Core/StructuredDataImpl.h
lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py

Removed: 




diff  --git a/lldb/include/lldb/Core/StructuredDataImpl.h 
b/lldb/include/lldb/Core/StructuredDataImpl.h
index 9aea645a3ea6..929ce21fb2f9 100644
--- a/lldb/include/lldb/Core/StructuredDataImpl.h
+++ b/lldb/include/lldb/Core/StructuredDataImpl.h
@@ -68,14 +68,18 @@ class StructuredDataImpl {
   return error;
 }
 
-// Grab the plugin.
-auto plugin_sp = lldb::StructuredDataPluginSP(m_plugin_wp);
+// Grab the plugin
+lldb::StructuredDataPluginSP plugin_sp = m_plugin_wp.lock();
+
+// If there's no plugin, call underlying data's dump method:
 if (!plugin_sp) {
-  error.SetErrorString("Cannot pretty print structured data: "
-   "plugin doesn't exist.");
+  if (!m_data_sp) {
+error.SetErrorString("No data to describe.");
+return error;
+  }
+  m_data_sp->Dump(stream, true);
   return error;
 }
-
 // Get the data's description.
 return plugin_sp->GetDescription(m_data_sp, stream);
   }

diff  --git 
a/lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py 
b/lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
index f5efdfa8b37f..a1a318517bed 100644
--- a/lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
+++ b/lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
@@ -35,6 +35,13 @@ def structured_data_api_test(self):
 # Tests for invalid data type
 self.invalid_struct_test(example)
 
+# Test that GetDescription works:
+s.Clear()
+error = example.GetDescription(s)
+self.assertTrue(error.Success(), "GetDescription works")
+if not "key_float" in s.GetData():
+self.fail("FAILED: could not find key_float in description output")
+
 dict_struct = lldb.SBStructuredData()
 dict_struct = example.GetValueForKey("key_dict")
 



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

Re: [Lldb-commits] [lldb] 1b1d981 - Revert "Revert "Add the ability to write target stop-hooks using the ScriptInterpreter.""

[Jim Ingham via lldb-commits]

I also used to get e-mails when a test failed and I was on the changes list.  
But I haven’t gotten any failure e-mails.  Does that only happen for some of 
the bots (or has that stopped working) or should I look to my filters?

Jim


> On Sep 30, 2020, at 10:40 AM, Jim Ingham via lldb-commits 
>  wrote:
> 
> It looks like all the failing builds are incremental builds.  Can you kick 
> off a clean build and see if that also gets a failure?  I’m worried that all 
> the SWIG bits aren’t getting rebuilt.  The code that is failing here is not 
> at all time dependent, or particularly platform specific, so it would be odd 
> for it to fail on ubuntu but not anywhere else.
> 
> Jim
> 
> 
>> On Sep 30, 2020, at 5:50 AM, Pavel Labath  wrote:
>> 
>> It looks like the new test (TestStopHookScripted.py) is flaky:
>> http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/18360/steps/test/logs/stdio
>> http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/9484/steps/test/logs/stdio
>> http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/9504/steps/test/logs/stdio
>> http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/9505/steps/test/logs/stdio
>> 
>> On 29/09/2020 21:01, Jim Ingham via lldb-commits wrote:
>>> 
>>> Author: Jim Ingham
>>> Date: 2020-09-29T12:01:14-07:00
>>> New Revision: 1b1d9815987a753f2f3524cfad050b85972dae5b
>>> 
>>> URL: 
>>> https://github.com/llvm/llvm-project/commit/1b1d9815987a753f2f3524cfad050b85972dae5b
>>> DIFF: 
>>> https://github.com/llvm/llvm-project/commit/1b1d9815987a753f2f3524cfad050b85972dae5b.diff
>>> 
>>> LOG: Revert "Revert "Add the ability to write target stop-hooks using the 
>>> ScriptInterpreter.""
>>> 
>>> This reverts commit f775fe59640a2e837ad059a8f40e26989d4f9831.
>>> 
>>> I fixed a return type error in the original patch that was causing a test 
>>> failure.
>>> Also added a REQUIRES: python to the shell test so we'll skip this for
>>> people who build lldb w/o Python.
>>> Also added another test for the error printing.
>>> 
>>> Added: 
>>>   lldb/test/API/commands/target/stop-hooks/TestStopHookScripted.py
>>>   lldb/test/API/commands/target/stop-hooks/stop_hook.py
>>>   lldb/test/Shell/Commands/Inputs/stop_hook.py
>>>   lldb/test/Shell/Commands/command-stop-hook-output.test
>>> 
>>> Modified: 
>>>   lldb/bindings/python/python-swigsafecast.swig
>>>   lldb/bindings/python/python-wrapper.swig
>>>   lldb/docs/use/python-reference.rst
>>>   lldb/include/lldb/Interpreter/ScriptInterpreter.h
>>>   lldb/include/lldb/Symbol/SymbolContext.h
>>>   lldb/include/lldb/Target/Target.h
>>>   lldb/source/Commands/CommandObjectTarget.cpp
>>>   lldb/source/Commands/Options.td
>>>   lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
>>>   lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
>>>   lldb/source/Symbol/SymbolContext.cpp
>>>   lldb/source/Target/Target.cpp
>>>   lldb/test/API/commands/target/stop-hooks/TestStopHooks.py
>>>   lldb/test/API/commands/target/stop-hooks/main.c
>>>   lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
>>> 
>>> Removed: 
>>> 
>>> 
>>> 
>>> 
>>> diff  --git a/lldb/bindings/python/python-swigsafecast.swig 
>>> b/lldb/bindings/python/python-swigsafecast.swig
>>> index d5cafbfa67cb..091fc29b1057 100644
>>> --- a/lldb/bindings/python/python-swigsafecast.swig
>>> +++ b/lldb/bindings/python/python-swigsafecast.swig
>>> @@ -152,3 +152,10 @@ SBTypeToSWIGWrapper (lldb::SBSymbolContext* sym_ctx_sb)
>>> {
>>>return SWIG_NewPointerObj((void *) sym_ctx_sb, 
>>> SWIGTYPE_p_lldb__SBSymbolContext, 0);
>>> }
>>> +
>>> +template <>
>>> +PyObject*
>>> +SBTypeToSWIGWrapper (lldb::SBStream* stream_sb)
>>> +{
>>> +return SWIG_NewPointerObj((void *) stream_sb, 
>>> SWIGTYPE_p_lldb__SBStream, 0);
>>> +}
>>> 
>>> diff  --git a/lldb/bindings/python/python-wrapper.swig 
>>> b/lldb/bindings/python/python-wrapper.swig
>>> index 516590ed5771..c00deba6073b 100644
>>> --- a/lldb/bindings/python/python-wrapper.swig
>>> +++ b/lldb/bindings/python/python-wrapper.swig
>>> @@ -468,6 +468,127 @@ LLDBSwigPythonCallBreakpointResolver
>>>return ret_val;
>>> }
>>> 
>>> +SWIGEXPORT void *
>>> +LLDBSwigPythonCreateScriptedStopHook
>>> +(
>>> +lldb::TargetSP target_sp,
>>> +const char *python_class_name,
>>> +const char *session_dictionary_name,
>>> +lldb_private::StructuredDataImpl *args_impl,
>>> +Status 
>>> +)
>>> +{
>>> +if (python_class_name == NULL || python_class_name[0] == '\0') {
>>> +error.SetErrorString("Empty class name.");
>>> +Py_RETURN_NONE;
>>> +}
>>> +if (!session_dictionary_name) {
>>> +  error.SetErrorString("No session dictionary");
>>> +  Py_RETURN_NONE;
>>> +}
>>> +
>>> +PyErr_Cleaner py_err_cleaner(true);
>>> +
>>> +auto dict = 
>>> +PythonModule::MainModule().ResolveName(
>>> +session_dictionary_name);
>>> +

[Lldb-commits] [PATCH] D88513: [lldb-vscode] Allow an empty 'breakpoints' field to clear breakpoints.

[Jordan Rupprecht via Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
rupprecht marked an inline comment as done.
Closed by commit rGad865d9d10b8: [lldb-vscode] Allow an empty 
breakpoints field to clear breakpoints. (authored by rupprecht).

Changed prior to commit:
  https://reviews.llvm.org/D88513?vs=295124=295364#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88513

Files:
  lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
  lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
  lldb/tools/lldb-vscode/lldb-vscode.cpp

Index: lldb/tools/lldb-vscode/lldb-vscode.cpp
===
--- lldb/tools/lldb-vscode/lldb-vscode.cpp
+++ lldb/tools/lldb-vscode/lldb-vscode.cpp
@@ -1936,27 +1936,32 @@
 
   // Decode the source breakpoint infos for this "setBreakpoints" request
   SourceBreakpointMap request_bps;
-  for (const auto  : *breakpoints) {
-auto bp_obj = bp.getAsObject();
-if (bp_obj) {
-  SourceBreakpoint src_bp(*bp_obj);
-  request_bps[src_bp.line] = src_bp;
-
-  // We check if this breakpoint already exists to update it
-  auto existing_source_bps = g_vsc.source_breakpoints.find(path);
-  if (existing_source_bps != g_vsc.source_breakpoints.end()) {
-const auto _bp = existing_source_bps->second.find(src_bp.line);
-if (existing_bp != existing_source_bps->second.end()) {
-  existing_bp->second.UpdateBreakpoint(src_bp);
-  AppendBreakpoint(existing_bp->second.bp, response_breakpoints, path,
-   src_bp.line);
-  continue;
+  // "breakpoints" may be unset, in which case we treat it the same as being set
+  // to an empty array.
+  if (breakpoints) {
+for (const auto  : *breakpoints) {
+  auto bp_obj = bp.getAsObject();
+  if (bp_obj) {
+SourceBreakpoint src_bp(*bp_obj);
+request_bps[src_bp.line] = src_bp;
+
+// We check if this breakpoint already exists to update it
+auto existing_source_bps = g_vsc.source_breakpoints.find(path);
+if (existing_source_bps != g_vsc.source_breakpoints.end()) {
+  const auto _bp =
+  existing_source_bps->second.find(src_bp.line);
+  if (existing_bp != existing_source_bps->second.end()) {
+existing_bp->second.UpdateBreakpoint(src_bp);
+AppendBreakpoint(existing_bp->second.bp, response_breakpoints, path,
+ src_bp.line);
+continue;
+  }
 }
+// At this point the breakpoint is new
+src_bp.SetBreakpoint(path.data());
+AppendBreakpoint(src_bp.bp, response_breakpoints, path, src_bp.line);
+g_vsc.source_breakpoints[path][src_bp.line] = std::move(src_bp);
   }
-  // At this point the breakpoint is new
-  src_bp.SetBreakpoint(path.data());
-  AppendBreakpoint(src_bp.bp, response_breakpoints, path, src_bp.line);
-  g_vsc.source_breakpoints[path][src_bp.line] = std::move(src_bp);
 }
   }
 
Index: lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
===
--- lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
+++ lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
@@ -219,6 +219,48 @@
 self.assertTrue(breakpoint['verified'],
 "expect breakpoint still verified")
 
+@skipIfWindows
+@skipIfRemote
+def test_clear_breakpoints_unset_breakpoints(self):
+'''Test clearing breakpoints like test_set_and_clear, but clear
+   breakpoints by omitting the breakpoints array instead of sending an
+   empty one.'''
+lines = [line_number('main.cpp', 'break 12'),
+ line_number('main.cpp', 'break 13')]
+
+# Visual Studio Code Debug Adaptors have no way to specify the file
+# without launching or attaching to a process, so we must start a
+# process in order to be able to set breakpoints.
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+
+# Set one breakpoint and verify that it got set correctly.
+response = self.vscode.request_setBreakpoints(self.main_path, lines)
+line_to_id = {}
+breakpoints = response['body']['breakpoints']
+self.assertEquals(len(breakpoints), len(lines),
+"expect %u source breakpoints" % (len(lines)))
+for (breakpoint, index) in zip(breakpoints, range(len(lines))):
+line = breakpoint['line']
+self.assertTrue(line, lines[index])
+# Store the "id" of the breakpoint that was set for later
+line_to_id[line] = breakpoint['id']
+

[Lldb-commits] [lldb] ad865d9 - [lldb-vscode] Allow an empty 'breakpoints' field to clear breakpoints.

[Jordan Rupprecht via lldb-commits]

Author: Jordan Rupprecht
Date: 2020-09-30T11:32:06-07:00
New Revision: ad865d9d10b8cf93738470175aae1be7a4a3eb6b

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

LOG: [lldb-vscode] Allow an empty 'breakpoints' field to clear breakpoints.

Per the DAP spec for SetBreakpoints [1], the way to clear breakpoints is: `To 
clear all breakpoint for a source, specify an empty array.`

However, leaving the breakpoints field unset is also a well formed request 
(note the `breakpoints?:` in the `SetBreakpointsArguments` definition). If it's 
unset, we have a couple choices:

1. Crash (current behavior)
2. Clear breakpoints
3. Return an error response that the breakpoints field is missing.

I propose we do (2) instead of (1), and treat an unset breakpoints field the 
same as an empty breakpoints field.

[1] 
https://microsoft.github.io/debug-adapter-protocol/specification#Requests_SetBreakpoints

Reviewed By: wallace, labath

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

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
lldb/tools/lldb-vscode/lldb-vscode.cpp

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
index 834e33ef5c3d..70f29cdd3d75 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
@@ -728,24 +728,26 @@ def request_scopes(self, frameId):
 def request_setBreakpoints(self, file_path, line_array, condition=None,
hitCondition=None):
 (dir, base) = os.path.split(file_path)
-breakpoints = []
-for line in line_array:
-bp = {'line': line}
-if condition is not None:
-bp['condition'] = condition
-if hitCondition is not None:
-bp['hitCondition'] = hitCondition
-breakpoints.append(bp)
 source_dict = {
 'name': base,
 'path': file_path
 }
 args_dict = {
 'source': source_dict,
-'breakpoints': breakpoints,
-'lines': '%s' % (line_array),
 'sourceModified': False,
 }
+if line_array is not None:
+args_dict['lines'] = '%s' % line_array
+breakpoints = []
+for line in line_array:
+bp = {'line': line}
+if condition is not None:
+bp['condition'] = condition
+if hitCondition is not None:
+bp['hitCondition'] = hitCondition
+breakpoints.append(bp)
+args_dict['breakpoints'] = breakpoints
+
 command_dict = {
 'command': 'setBreakpoints',
 'type': 'request',

diff  --git 
a/lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py 
b/lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
index c08c4d70489f..23f4ad216ea2 100644
--- a/lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
+++ b/lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
@@ -219,6 +219,48 @@ def test_set_and_clear(self):
 self.assertTrue(breakpoint['verified'],
 "expect breakpoint still verified")
 
+@skipIfWindows
+@skipIfRemote
+def test_clear_breakpoints_unset_breakpoints(self):
+'''Test clearing breakpoints like test_set_and_clear, but clear
+   breakpoints by omitting the breakpoints array instead of sending an
+   empty one.'''
+lines = [line_number('main.cpp', 'break 12'),
+ line_number('main.cpp', 'break 13')]
+
+# Visual Studio Code Debug Adaptors have no way to specify the file
+# without launching or attaching to a process, so we must start a
+# process in order to be able to set breakpoints.
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+
+# Set one breakpoint and verify that it got set correctly.
+response = self.vscode.request_setBreakpoints(self.main_path, lines)
+line_to_id = {}
+breakpoints = response['body']['breakpoints']
+self.assertEquals(len(breakpoints), len(lines),
+"expect %u source breakpoints" % (len(lines)))
+for (breakpoint, index) in zip(breakpoints, range(len(lines))):
+line = breakpoint['line']
+self.assertTrue(line, lines[index])
+# Store the "id" of the breakpoint that was set for later
+

[Lldb-commits] [lldb] c3193e4 - [lldb/ipv6] Support running lldb tests in an ipv6-only environment.

[Jordan Rupprecht via lldb-commits]

Author: Jordan Rupprecht
Date: 2020-09-30T11:08:41-07:00
New Revision: c3193e464cbd5e8b7cade103032c222bf8bc0e27

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

LOG: [lldb/ipv6] Support running lldb tests in an ipv6-only environment.

When running in an ipv6-only environment where `AF_INET` sockets are not 
available, many lldb tests (mostly gdb remote tests) fail because things like 
`127.0.0.1` don't work there.

Use `localhost` instead of `127.0.0.1` whenever possible, or include a fallback 
of creating `AF_INET6` sockets when `AF_INET` fails.

Reviewed By: labath

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

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
lldb/test/API/functionalities/gdb_remote_client/gdbclientutils.py
lldb/test/API/tools/lldb-server/commandline/TestStubReverseConnect.py
lldb/tools/lldb-server/lldb-gdbserver.cpp
lldb/unittests/Host/SocketTest.cpp
lldb/unittests/Host/SocketTestUtilities.cpp

Removed: 




diff  --git 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
index 253fd35d461e..7d7b61c8610d 100644
--- 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
+++ 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
@@ -318,7 +318,13 @@ def _verify_socket(self, sock):
 raise _ConnectionRefused()  # Got EOF, connection dropped.
 
 def create_socket(self):
-sock = socket.socket()
+try:
+sock = socket.socket(family=socket.AF_INET)
+except OSError as e:
+if e.errno != errno.EAFNOSUPPORT:
+raise
+sock = socket.socket(family=socket.AF_INET6)
+
 logger = self.logger
 
 triple = self.dbg.GetSelectedPlatform().GetTriple()
@@ -379,7 +385,7 @@ def get_debug_monitor_command_line_args(self, 
attach_pid=None):
 ["*:{}".format(self.port)]
 else:
 commandline_args = self.debug_monitor_extra_args + \
-["127.0.0.1:{}".format(self.port)]
+["localhost:{}".format(self.port)]
 
 if attach_pid:
 commandline_args += ["--attach=%d" % attach_pid]

diff  --git a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp 
b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
index 832760f7f0dc..4981345d6a18 100644
--- a/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
@@ -1234,7 +1234,7 @@ 
GDBRemoteCommunication::ConnectLocally(GDBRemoteCommunication ,
   const int backlog = 5;
   TCPSocket listen_socket(true, child_processes_inherit);
   if (llvm::Error error =
-  listen_socket.Listen("127.0.0.1:0", backlog).ToError())
+  listen_socket.Listen("localhost:0", backlog).ToError())
 return error;
 
   Socket *accept_socket;
@@ -1243,7 +1243,7 @@ 
GDBRemoteCommunication::ConnectLocally(GDBRemoteCommunication ,
 
   llvm::SmallString<32> remote_addr;
   llvm::raw_svector_ostream(remote_addr)
-  << "connect://127.0.0.1:" << listen_socket.GetLocalPortNumber();
+  << "connect://localhost:" << listen_socket.GetLocalPortNumber();
 
   std::unique_ptr conn_up(
   new ConnectionFileDescriptor());

diff  --git a/lldb/test/API/functionalities/gdb_remote_client/gdbclientutils.py 
b/lldb/test/API/functionalities/gdb_remote_client/gdbclientutils.py
index eb789e861d9c..dabe9423434d 100644
--- a/lldb/test/API/functionalities/gdb_remote_client/gdbclientutils.py
+++ b/lldb/test/API/functionalities/gdb_remote_client/gdbclientutils.py
@@ -1,3 +1,4 @@
+import errno
 import os
 import os.path
 import threading
@@ -317,12 +318,20 @@ class MockGDBServer:
 def __init__(self, port = 0):
 self.responder = MockGDBServerResponder()
 self.port = port
-self._socket = socket.socket()
+try:
+self._socket = socket.socket(family=socket.AF_INET)
+except OSError as e:
+if e.errno != errno.EAFNOSUPPORT:
+raise
+self._socket = socket.socket(family=socket.AF_INET6)
 
 def start(self):
 # Block until the socket is up, so self.port is available immediately.
 # Then start a thread that waits for a client connection.
-addr = ("127.0.0.1", self.port)
+if self._socket.family == socket.AF_INET:
+addr = ("127.0.0.1", self.port)
+elif self._socket.family == socket.AF_INET6:
+addr = ("::1", self.port)
 self._socket.bind(addr)

[Lldb-commits] [PATCH] D87333: [lldb/ipv6] Support running lldb tests in an ipv6-only environment.

[Jordan Rupprecht via Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGc3193e464cbd: [lldb/ipv6] Support running lldb tests in an 
ipv6-only environment. (authored by rupprecht).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87333

Files:
  lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
  lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
  lldb/test/API/functionalities/gdb_remote_client/gdbclientutils.py
  lldb/test/API/tools/lldb-server/commandline/TestStubReverseConnect.py
  lldb/tools/lldb-server/lldb-gdbserver.cpp
  lldb/unittests/Host/SocketTest.cpp
  lldb/unittests/Host/SocketTestUtilities.cpp

Index: lldb/unittests/Host/SocketTestUtilities.cpp
===
--- lldb/unittests/Host/SocketTestUtilities.cpp
+++ lldb/unittests/Host/SocketTestUtilities.cpp
@@ -101,13 +101,14 @@
  "Creating a canary {0} TCP socket failed: {1}.",
  Proto, Err)
  .str();
-  bool HasAddrNotAvail = false;
+  bool HasProtocolError = false;
   handleAllErrors(std::move(Err), [&](std::unique_ptr ECErr) {
-if (ECErr->convertToErrorCode() ==
-std::make_error_code(std::errc::address_not_available))
-  HasAddrNotAvail = true;
+std::error_code ec = ECErr->convertToErrorCode();
+if (ec == std::make_error_code(std::errc::address_family_not_supported) ||
+ec == std::make_error_code(std::errc::address_not_available))
+  HasProtocolError = true;
   });
-  if (HasAddrNotAvail) {
+  if (HasProtocolError) {
 GTEST_LOG_(WARNING)
 << llvm::formatv(
"Assuming the host does not support {0}. Skipping test.", Proto)
Index: lldb/unittests/Host/SocketTest.cpp
===
--- lldb/unittests/Host/SocketTest.cpp
+++ lldb/unittests/Host/SocketTest.cpp
@@ -14,12 +14,24 @@
 
 using namespace lldb_private;
 
-class SocketTest : public testing::Test {
+struct SocketTestParams {
+  bool is_ipv6;
+  std::string localhost_ip;
+};
+
+class SocketTest : public testing::TestWithParam {
 public:
   SubsystemRAII subsystems;
+
+protected:
+  bool HostSupportsProtocol() const {
+if (GetParam().is_ipv6)
+  return HostSupportsIPv6();
+return HostSupportsIPv4();
+  }
 };
 
-TEST_F(SocketTest, DecodeHostAndPort) {
+TEST_P(SocketTest, DecodeHostAndPort) {
   std::string host_str;
   std::string port_str;
   int32_t port;
@@ -86,7 +98,7 @@
 }
 
 #if LLDB_ENABLE_POSIX
-TEST_F(SocketTest, DomainListenConnectAccept) {
+TEST_P(SocketTest, DomainListenConnectAccept) {
   llvm::SmallString<64> Path;
   std::error_code EC = llvm::sys::fs::createUniqueDirectory("DomainListenConnectAccept", Path);
   ASSERT_FALSE(EC);
@@ -102,18 +114,22 @@
 }
 #endif
 
-TEST_F(SocketTest, TCPListen0ConnectAccept) {
+TEST_P(SocketTest, TCPListen0ConnectAccept) {
+  if (!HostSupportsProtocol())
+return;
   std::unique_ptr socket_a_up;
   std::unique_ptr socket_b_up;
-  CreateTCPConnectedSockets("127.0.0.1", _a_up, _b_up);
+  CreateTCPConnectedSockets(GetParam().localhost_ip, _a_up,
+_b_up);
 }
 
-TEST_F(SocketTest, TCPGetAddress) {
+TEST_P(SocketTest, TCPGetAddress) {
   std::unique_ptr socket_a_up;
   std::unique_ptr socket_b_up;
-  if (!HostSupportsIPv4())
+  if (!HostSupportsProtocol())
 return;
-  CreateTCPConnectedSockets("127.0.0.1", _a_up, _b_up);
+  CreateTCPConnectedSockets(GetParam().localhost_ip, _a_up,
+_b_up);
 
   EXPECT_EQ(socket_a_up->GetLocalPortNumber(),
 socket_b_up->GetRemotePortNumber());
@@ -121,11 +137,16 @@
 socket_a_up->GetRemotePortNumber());
   EXPECT_NE(socket_a_up->GetLocalPortNumber(),
 socket_b_up->GetLocalPortNumber());
-  EXPECT_STREQ("127.0.0.1", socket_a_up->GetRemoteIPAddress().c_str());
-  EXPECT_STREQ("127.0.0.1", socket_b_up->GetRemoteIPAddress().c_str());
+  EXPECT_STREQ(GetParam().localhost_ip.c_str(),
+   socket_a_up->GetRemoteIPAddress().c_str());
+  EXPECT_STREQ(GetParam().localhost_ip.c_str(),
+   socket_b_up->GetRemoteIPAddress().c_str());
 }
 
-TEST_F(SocketTest, UDPConnect) {
+TEST_P(SocketTest, UDPConnect) {
+  // UDPSocket::Connect() creates sockets with AF_INET (IPv4).
+  if (!HostSupportsIPv4())
+return;
   llvm::Expected> socket =
   UDPSocket::Connect("127.0.0.1:0", /*child_processes_inherit=*/false);
 
@@ -133,7 +154,9 @@
   EXPECT_TRUE(socket.get()->IsValid());
 }
 
-TEST_F(SocketTest, TCPListen0GetPort) {
+TEST_P(SocketTest, TCPListen0GetPort) {
+  if (!HostSupportsIPv4())
+return;
   Predicate port_predicate;
   port_predicate.SetValue(0, eBroadcastNever);
   llvm::Expected> sock =
@@ -143,12 +166,13 @@
   

Re: [Lldb-commits] [PATCH] D88266: Check that the "StructuredData Plugin weak pointer" is good before trying to turn it into a shared pointer

[Jim Ingham via lldb-commits]

We should probably outlaw the shared pointer from weak pointer constructor in 
lldb.  It looks like the only safe way to use it is in a try/catch block (or by 
preflighting the weak pointer with lock which renders it pretty much pointless.)

Jim


> On Sep 30, 2020, at 6:02 AM, Pavel Labath via Phabricator 
>  wrote:
> 
> labath added a comment.
> 
> In D88266#2302245 , @jingham wrote:
> 
>> Use std::weak_ptr::lock to make the shared pointer, rather than 
>> std::shared_ptr::shared_ptr(std::weak_ptr) (sort of), as the latter throws.
> 
> Yep, `wp.lock()` behaves differently from the shared_ptr constructor. :)
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D88266/new/
> 
> https://reviews.llvm.org/D88266
> 

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

Re: [Lldb-commits] [lldb] 1b1d981 - Revert "Revert "Add the ability to write target stop-hooks using the ScriptInterpreter.""

[Jim Ingham via lldb-commits]

It looks like all the failing builds are incremental builds.  Can you kick off 
a clean build and see if that also gets a failure?  I’m worried that all the 
SWIG bits aren’t getting rebuilt.  The code that is failing here is not at all 
time dependent, or particularly platform specific, so it would be odd for it to 
fail on ubuntu but not anywhere else.

Jim


> On Sep 30, 2020, at 5:50 AM, Pavel Labath  wrote:
> 
> It looks like the new test (TestStopHookScripted.py) is flaky:
> http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/18360/steps/test/logs/stdio
> http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/9484/steps/test/logs/stdio
> http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/9504/steps/test/logs/stdio
> http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/9505/steps/test/logs/stdio
> 
> On 29/09/2020 21:01, Jim Ingham via lldb-commits wrote:
>> 
>> Author: Jim Ingham
>> Date: 2020-09-29T12:01:14-07:00
>> New Revision: 1b1d9815987a753f2f3524cfad050b85972dae5b
>> 
>> URL: 
>> https://github.com/llvm/llvm-project/commit/1b1d9815987a753f2f3524cfad050b85972dae5b
>> DIFF: 
>> https://github.com/llvm/llvm-project/commit/1b1d9815987a753f2f3524cfad050b85972dae5b.diff
>> 
>> LOG: Revert "Revert "Add the ability to write target stop-hooks using the 
>> ScriptInterpreter.""
>> 
>> This reverts commit f775fe59640a2e837ad059a8f40e26989d4f9831.
>> 
>> I fixed a return type error in the original patch that was causing a test 
>> failure.
>> Also added a REQUIRES: python to the shell test so we'll skip this for
>> people who build lldb w/o Python.
>> Also added another test for the error printing.
>> 
>> Added: 
>>lldb/test/API/commands/target/stop-hooks/TestStopHookScripted.py
>>lldb/test/API/commands/target/stop-hooks/stop_hook.py
>>lldb/test/Shell/Commands/Inputs/stop_hook.py
>>lldb/test/Shell/Commands/command-stop-hook-output.test
>> 
>> Modified: 
>>lldb/bindings/python/python-swigsafecast.swig
>>lldb/bindings/python/python-wrapper.swig
>>lldb/docs/use/python-reference.rst
>>lldb/include/lldb/Interpreter/ScriptInterpreter.h
>>lldb/include/lldb/Symbol/SymbolContext.h
>>lldb/include/lldb/Target/Target.h
>>lldb/source/Commands/CommandObjectTarget.cpp
>>lldb/source/Commands/Options.td
>>lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
>>lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
>>lldb/source/Symbol/SymbolContext.cpp
>>lldb/source/Target/Target.cpp
>>lldb/test/API/commands/target/stop-hooks/TestStopHooks.py
>>lldb/test/API/commands/target/stop-hooks/main.c
>>lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
>> 
>> Removed: 
>> 
>> 
>> 
>> 
>> diff  --git a/lldb/bindings/python/python-swigsafecast.swig 
>> b/lldb/bindings/python/python-swigsafecast.swig
>> index d5cafbfa67cb..091fc29b1057 100644
>> --- a/lldb/bindings/python/python-swigsafecast.swig
>> +++ b/lldb/bindings/python/python-swigsafecast.swig
>> @@ -152,3 +152,10 @@ SBTypeToSWIGWrapper (lldb::SBSymbolContext* sym_ctx_sb)
>> {
>> return SWIG_NewPointerObj((void *) sym_ctx_sb, 
>> SWIGTYPE_p_lldb__SBSymbolContext, 0);
>> }
>> +
>> +template <>
>> +PyObject*
>> +SBTypeToSWIGWrapper (lldb::SBStream* stream_sb)
>> +{
>> +return SWIG_NewPointerObj((void *) stream_sb, 
>> SWIGTYPE_p_lldb__SBStream, 0);
>> +}
>> 
>> diff  --git a/lldb/bindings/python/python-wrapper.swig 
>> b/lldb/bindings/python/python-wrapper.swig
>> index 516590ed5771..c00deba6073b 100644
>> --- a/lldb/bindings/python/python-wrapper.swig
>> +++ b/lldb/bindings/python/python-wrapper.swig
>> @@ -468,6 +468,127 @@ LLDBSwigPythonCallBreakpointResolver
>> return ret_val;
>> }
>> 
>> +SWIGEXPORT void *
>> +LLDBSwigPythonCreateScriptedStopHook
>> +(
>> +lldb::TargetSP target_sp,
>> +const char *python_class_name,
>> +const char *session_dictionary_name,
>> +lldb_private::StructuredDataImpl *args_impl,
>> +Status 
>> +)
>> +{
>> +if (python_class_name == NULL || python_class_name[0] == '\0') {
>> +error.SetErrorString("Empty class name.");
>> +Py_RETURN_NONE;
>> +}
>> +if (!session_dictionary_name) {
>> +  error.SetErrorString("No session dictionary");
>> +  Py_RETURN_NONE;
>> +}
>> +
>> +PyErr_Cleaner py_err_cleaner(true);
>> +
>> +auto dict = 
>> +PythonModule::MainModule().ResolveName(
>> +session_dictionary_name);
>> +auto pfunc = 
>> +PythonObject::ResolveNameWithDictionary(
>> +python_class_name, dict);
>> +
>> +if (!pfunc.IsAllocated()) {
>> +error.SetErrorStringWithFormat("Could not find class: %s.", 
>> +   python_class_name);
>> +return nullptr;
>> +}
>> +
>> +lldb::SBTarget *target_val 
>> += new lldb::SBTarget(target_sp);
>> +
>> + 

[Lldb-commits] [PATCH] D88583: [lldb] [test/Register] Add partial read/write tests for x87 regs

[Michał Górny via Phabricator via lldb-commits]

mgorny created this revision.
mgorny added reviewers: labath, krytarowski.
Herald added a project: LLDB.
mgorny requested review of this revision.
Herald added a subscriber: JDevlieghere.

Add a partial read/write tests for x87 FPU registers.  This includes
reading and writing ST registers, reading basic control registers
in exception state (including operand code) and writing basic control
registers in non-exception state (marking the registers as used,
practically speaking).

The tests assume the current (roughly incorrect) behavior of reporting
the 'abridged' 8-bit ftag state as 16-bit ftag.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D88583

Files:
  lldb/test/Shell/Register/Inputs/x86-fp-read.cpp
  lldb/test/Shell/Register/Inputs/x86-fp-write.cpp
  lldb/test/Shell/Register/x86-fp-read.test
  lldb/test/Shell/Register/x86-fp-write.test

Index: lldb/test/Shell/Register/x86-fp-write.test
===
--- /dev/null
+++ lldb/test/Shell/Register/x86-fp-write.test
@@ -0,0 +1,35 @@
+# REQUIRES: native && (target-x86 || target-x86_64)
+# RUN: %clangxx_host %p/Inputs/x86-fp-write.cpp -o %t
+# RUN: %lldb -b -s %s %t | FileCheck %s
+process launch
+
+register write fctrl 0x037f
+register write fstat 0x0841
+# note: this needs to enable all registers for writes to be effective
+# TODO: fix it to use proper ftag values instead of 'abridged'
+register write ftag 0x00ff
+register write st0 "{0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0x00 0x40}"
+register write st1 "{0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x3f 0x00 0x00}"
+register write st2 "{0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}"
+register write st3 "{0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80}"
+register write st4 "{0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0xff 0x7f}"
+register write st5 "{0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0xff 0xff}"
+register write st6 "{0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xc0 0xff 0xff}"
+register write st7 "{0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}"
+
+process continue
+
+# CHECK-DAG: fctrl = 0x037f
+# CHECK-DAG: fstat = 0x0841
+# CHECK-DAG: ftag = 0xa961
+
+# CHECK-DAG: st0 = { 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0x00 0x40 }
+# CHECK-DAG: st1 = { 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x3f 0x00 0x00 }
+# CHECK-DAG: st2 = { 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 }
+# CHECK-DAG: st3 = { 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 }
+# CHECK-DAG: st4 = { 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0xff 0x7f }
+# CHECK-DAG: st5 = { 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0xff 0xff }
+# CHECK-DAG: st6 = { 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xc0 0xff 0xff }
+# CHECK-DAG: st7 = { 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 }
+
+# CHECK: Process {{[0-9]+}} exited with status = 0
Index: lldb/test/Shell/Register/x86-fp-read.test
===
--- /dev/null
+++ lldb/test/Shell/Register/x86-fp-read.test
@@ -0,0 +1,24 @@
+# REQUIRES: native && (target-x86 || target-x86_64)
+# RUN: %clangxx_host %p/Inputs/x86-fp-read.cpp -o %t
+# RUN: %lldb -b -s %s %t | FileCheck %s
+process launch
+
+register read --all
+# CHECK-DAG: fctrl = 0x037e
+# CHECK-DAG: fstat = 0x88c1
+# TODO: the following value is incorrect, it's a bug in the way
+# FXSAVE/XSAVE is interpreted; it should be 0xa963 once fixed
+# CHECK-DAG: ftag = 0x00fe
+# CHECK-DAG: fop = 0x04f7
+
+# CHECK-DAG: st0 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0x00 0x40}
+# CHECK-DAG: st1 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x3f 0x00 0x00}
+# CHECK-DAG: st2 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
+# CHECK-DAG: st3 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80}
+# CHECK-DAG: st4 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0xff 0x7f}
+# CHECK-DAG: st5 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0xff 0xff}
+# CHECK-DAG: st6 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xc0 0xff 0xff}
+# CHECK-DAG: st7 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
+
+process continue
+# CHECK: Process {{[0-9]+}} exited with status = 0
Index: lldb/test/Shell/Register/Inputs/x86-fp-write.cpp
===
--- /dev/null
+++ lldb/test/Shell/Register/Inputs/x86-fp-write.cpp
@@ -0,0 +1,41 @@
+#include 
+#include 
+
+struct alignas(16) float80_raw {
+  uint8_t data[10];
+};
+
+int main() {
+  float80_raw st[8];
+  uint16_t env[14];
+
+  asm volatile(
+"finit\n\t"
+"int3\n\t"
+"fstenv %1\n\t"
+"fstpt 0x00(%0)\n\t"
+"fstpt 0x10(%0)\n\t"
+"fstpt 0x20(%0)\n\t"
+"fstpt 0x30(%0)\n\t"
+"fstpt 0x40(%0)\n\t"
+"fstpt 0x50(%0)\n\t"
+"fstpt 0x60(%0)\n\t"
+"fstpt 0x70(%0)\n\t"
+:
+: "a"(st), "m"(env)
+: "st"
+  );
+
+  printf("fctrl = 0x%04x\n", env[0]);
+  printf("fstat = 0x%04x\n", env[2]);
+  printf("ftag = 0x%04x\n", env[4]);
+
+  for (int i = 0; i < 8; ++i) {
+printf("st%d = { ", i);
+for (int j = 0; j < sizeof(st->data); ++j)
+  

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

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: lldb/unittests/SymbolFile/DWARF/SymbolFileDWARFTests.cpp:369
+  EXPECT_EQ(section_sp->GetType(), eSectionTypeCode);
+}

clayborg wrote:
> I would rather deal with an  C++ unit test any day. Trying to track down what 
> set of convoluted command line commands reproduce some lit test is quite 
> annoying and takes me a lot more time to debug. I think this test is targeted 
> and tests what is needed. I would vote to keep this one over converting to a 
> text dump test. My main reasoning is that it isn't possible to re-create a 
> compilable test case that will survive any compiler that it used (past, 
> present and future), and all symbol resolution is done bone using this call 
> in all cases. When something goes wrong, very easy to compile the binary and 
> debug.
If we put this up for a vote, I think you'd be in the minority. :)

I'm not sure what you find hard about reproducing a lit test -- the commands to 
do that get printed as a part of the test. And most of the time you don't need 
to run all the command to reproduce it -- running the last one suffices as the 
intermediate files are left over from the previous test run. I consider the 
leftover temporaries as one of the best aspects of this method. In this case, I 
could for example run llvm-dwarfdump on the intermediate object file to better 
understand the input that lldb gets.

Note that I am not advocating changing the test input to c++ source. I think 
the yaml is just fine (if I was writing it, I would probably have made that an 
assembler file). I just meant changing the test method by prefixing the yaml 
with something like:
```
# RUN: yaml2obj %s > %t
# RUN: %lldb %t -b -o "image lookup -f main.cpp -l 2" | FileCheck %s
# CHECK: LineEntry: {{.*}}main.cpp:2 # or something like that
```


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] D87868: [RFC] When calling the process mmap try to call all found instead of just the first one

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

A completely different approach would be to avoid the mmap function completely, 
and go for the mmap syscall instead.

That is, instead of setting up registers to fake call to mmap and doing a 
run-to entry point breakpoint, we could set them up to fake a syscall, and then 
do an instruction-step over a syscall instruction (which we could place at the 
entry point, or find a suitable one in the binary).

The advantage of that would be that this would work not only in this 
(sanitizer) case, but also in all other cases where an mmap symbol is not 
present/functional/unambiguous:

- a bare-bone statically linked binary need not contain an mmap function
- very early in the program startup (before relocations are applied) it may not 
be safe to call the global mmap
- mmap may be buggy (libc debugging?)

Note that this would not need to be implemented in the lldb client. This sort 
of thing would be natural to implement in lldb server in response to the `_M` 
packet. There it would be easy to encode the abi details needed to issue a 
syscall. The client already prefers this packet, and the existing code could 
remain as a fallback for platforms not implementing it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87868

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

[Lldb-commits] [PATCH] D87333: [lldb/ipv6] Support running lldb tests in an ipv6-only environment.

[Pavel Labath via Phabricator via lldb-commits]

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

Sorry about the delay.

In D87333#2293266 , @clayborg wrote:

> I am fine with trying "localhost" and seeing if we run into any issues. 
> Hopefully slow DNS isn't a problem anymore on Macs. Everyone else ok?

Sounds good to me. I'm mainly hoping that with the use of socketpair(2), the 
DNS will not be on the critical path anymore.

In D87333#2274572 , @rupprecht wrote:

> Many non-reproducers tests fail w/o the change to 
> `GDBRemoteCommunication::ConnectLocally`, so it's at least used outside of 
> that.

Well... it is used in a bunch of tests exercising the socket functionality, but 
these are just tests. The only production usage is in reproducers. Which makes 
total sense when you think about it -- why would anyone be creating a socket 
for communicating within the same process -- there are much simpler ways to do 
that.

In D87333#2291317 , @rupprecht wrote:

> [1] IIUC, when connecting via hostname, attempting "localhost" will try both 
> AF_INET and AF_INET6, but there is no corresponding way to construct a raw 
> socket with automatic fallback to AF_INET6 if AF_INET does not work, so that 
> part is the same as before (try to create AF_INET and catch the error 
> manually)

The fully generic way to handle this would be to loop over 
getaddrinfo("localhost") and try to listen on each address that returns 
(multiple sockets). That is at least for the case when you don't know who is 
going to connect to you. For tests, it should be sufficient to pick a first 
address that works and use that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87333

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

[Lldb-commits] [lldb] 762e8f9 - [lldb] [Process/NetBSD] Fix operating on ftag register

[Michał Górny via lldb-commits]

Author: Michał Górny
Date: 2020-09-30T15:39:31+02:00
New Revision: 762e8f9bbdaf43300dbc75637a8bce1ce643cc06

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

LOG: [lldb] [Process/NetBSD] Fix operating on ftag register

Added: 


Modified: 
lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp 
b/lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
index ca4706a65657..af8b2a2ba794 100644
--- a/lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
+++ b/lldb/source/Plugins/Process/NetBSD/NativeRegisterContextNetBSD_x86_64.cpp
@@ -324,7 +324,7 @@ static constexpr int RegNumX86ToX86_64(int regnum) {
   case lldb_fstat_i386:
 return lldb_fstat_x86_64;
   case lldb_ftag_i386:
-return lldb_fstat_x86_64;
+return lldb_ftag_x86_64;
   case lldb_fop_i386:
 return lldb_fop_x86_64;
   case lldb_fiseg_i386:
@@ -651,7 +651,7 @@ NativeRegisterContextNetBSD_x86_64::ReadRegister(const 
RegisterInfo *reg_info,
 reg_value = (uint16_t)m_fpr.fxstate.fx_sw;
 break;
   case lldb_ftag_x86_64:
-reg_value = (uint8_t)m_fpr.fxstate.fx_tw;
+reg_value = (uint16_t)m_fpr.fxstate.fx_tw;
 break;
   case lldb_fop_x86_64:
 reg_value = (uint64_t)m_fpr.fxstate.fx_opcode;
@@ -939,7 +939,7 @@ Status NativeRegisterContextNetBSD_x86_64::WriteRegister(
 m_fpr.fxstate.fx_sw = reg_value.GetAsUInt16();
 break;
   case lldb_ftag_x86_64:
-m_fpr.fxstate.fx_tw = reg_value.GetAsUInt8();
+m_fpr.fxstate.fx_tw = reg_value.GetAsUInt16();
 break;
   case lldb_fop_x86_64:
 m_fpr.fxstate.fx_opcode = reg_value.GetAsUInt16();



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

[Lldb-commits] [PATCH] D88453: [lldb] Fix FreeBSD Arm Process Plugin build.

[Ed Maste via Phabricator via lldb-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf794160c6cb7: [lldb] Fix FreeBSD Arm Process Plugin build 
(authored by emaste).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88453

Files:
  lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.cpp
  lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.h


Index: 
lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.h
===
--- lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.h
+++ lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.h
@@ -70,6 +70,10 @@
   uint32_t NumSupportedHardwareWatchpoints();
 
 private:
+  RegisterInfoPOSIX_arm::GPR m_gpr_arm;
+
+  RegisterInfoPOSIX_arm::FPU m_fpr;
+
   ProcessMonitor ();
 };
 
Index: 
lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.cpp
===
--- 
lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.cpp
+++ 
lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.cpp
@@ -14,6 +14,7 @@
 #include "ProcessMonitor.h"
 #include "RegisterContextPOSIXProcessMonitor_arm.h"
 #include "Plugins/Process/Utility/RegisterContextPOSIX_arm.h"
+#include "Plugins/Process/Utility/lldb-arm-register-enums.h"
 
 using namespace lldb_private;
 using namespace lldb;


Index: lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.h
===
--- lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.h
+++ lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.h
@@ -70,6 +70,10 @@
   uint32_t NumSupportedHardwareWatchpoints();
 
 private:
+  RegisterInfoPOSIX_arm::GPR m_gpr_arm;
+
+  RegisterInfoPOSIX_arm::FPU m_fpr;
+
   ProcessMonitor ();
 };
 
Index: lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.cpp
===
--- lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.cpp
+++ lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.cpp
@@ -14,6 +14,7 @@
 #include "ProcessMonitor.h"
 #include "RegisterContextPOSIXProcessMonitor_arm.h"
 #include "Plugins/Process/Utility/RegisterContextPOSIX_arm.h"
+#include "Plugins/Process/Utility/lldb-arm-register-enums.h"
 
 using namespace lldb_private;
 using namespace lldb;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] f794160 - [lldb] Fix FreeBSD Arm Process Plugin build

[Ed Maste via lldb-commits]

Author: Ed Maste
Date: 2020-09-30T09:25:27-04:00
New Revision: f794160c6cb7da4b5ef354a91fe498341f651d36

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

LOG: [lldb] Fix FreeBSD Arm Process Plugin build

Add a missing include and some definitions in 76953321.

Patch by: Brooks Davis

Reviewed by: labath

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

Added: 


Modified: 

lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.cpp
lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.h

Removed: 




diff  --git 
a/lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.cpp
 
b/lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.cpp
index 2f4d613f767a..afb92e848466 100644
--- 
a/lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.cpp
+++ 
b/lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.cpp
@@ -14,6 +14,7 @@
 #include "ProcessMonitor.h"
 #include "RegisterContextPOSIXProcessMonitor_arm.h"
 #include "Plugins/Process/Utility/RegisterContextPOSIX_arm.h"
+#include "Plugins/Process/Utility/lldb-arm-register-enums.h"
 
 using namespace lldb_private;
 using namespace lldb;

diff  --git 
a/lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.h 
b/lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.h
index 12e1f19d32fa..906926fd9194 100644
--- 
a/lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.h
+++ 
b/lldb/source/Plugins/Process/FreeBSD/RegisterContextPOSIXProcessMonitor_arm.h
@@ -70,6 +70,10 @@ class RegisterContextPOSIXProcessMonitor_arm : public 
RegisterContextPOSIX_arm,
   uint32_t NumSupportedHardwareWatchpoints();
 
 private:
+  RegisterInfoPOSIX_arm::GPR m_gpr_arm;
+
+  RegisterInfoPOSIX_arm::FPU m_fpr;
+
   ProcessMonitor ();
 };
 



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

[Lldb-commits] [PATCH] D88266: Check that the "StructuredData Plugin weak pointer" is good before trying to turn it into a shared pointer

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D88266#2302245 , @jingham wrote:

> Use std::weak_ptr::lock to make the shared pointer, rather than 
> std::shared_ptr::shared_ptr(std::weak_ptr) (sort of), as the latter throws.

Yep, `wp.lock()` behaves differently from the shared_ptr constructor. :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88266

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

Re: [Lldb-commits] [lldb] 92e1ebe - [trace] Fix destructor declaration

[Pavel Labath via lldb-commits]

On 29/09/2020 22:09, Walter Erquinigo via lldb-commits wrote:
> The destructor must be defined in the implementation class so that it
> can be called

That doesn't sound right. Each class automatically gets a destructor if
it does not declare one itself. "~Foo() override = default" is
completely equivalent to omitting the destructor completely, if the base
destructor is virtual (which is true in this case, because the classes
inherit from PluginInterface).

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

Re: [Lldb-commits] [lldb] 1b1d981 - Revert "Revert "Add the ability to write target stop-hooks using the ScriptInterpreter.""

[Pavel Labath via lldb-commits]

It looks like the new test (TestStopHookScripted.py) is flaky:
http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/18360/steps/test/logs/stdio
http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/9484/steps/test/logs/stdio
http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/9504/steps/test/logs/stdio
http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/9505/steps/test/logs/stdio

On 29/09/2020 21:01, Jim Ingham via lldb-commits wrote:
> 
> Author: Jim Ingham
> Date: 2020-09-29T12:01:14-07:00
> New Revision: 1b1d9815987a753f2f3524cfad050b85972dae5b
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/1b1d9815987a753f2f3524cfad050b85972dae5b
> DIFF: 
> https://github.com/llvm/llvm-project/commit/1b1d9815987a753f2f3524cfad050b85972dae5b.diff
> 
> LOG: Revert "Revert "Add the ability to write target stop-hooks using the 
> ScriptInterpreter.""
> 
> This reverts commit f775fe59640a2e837ad059a8f40e26989d4f9831.
> 
> I fixed a return type error in the original patch that was causing a test 
> failure.
> Also added a REQUIRES: python to the shell test so we'll skip this for
> people who build lldb w/o Python.
> Also added another test for the error printing.
> 
> Added: 
> lldb/test/API/commands/target/stop-hooks/TestStopHookScripted.py
> lldb/test/API/commands/target/stop-hooks/stop_hook.py
> lldb/test/Shell/Commands/Inputs/stop_hook.py
> lldb/test/Shell/Commands/command-stop-hook-output.test
> 
> Modified: 
> lldb/bindings/python/python-swigsafecast.swig
> lldb/bindings/python/python-wrapper.swig
> lldb/docs/use/python-reference.rst
> lldb/include/lldb/Interpreter/ScriptInterpreter.h
> lldb/include/lldb/Symbol/SymbolContext.h
> lldb/include/lldb/Target/Target.h
> lldb/source/Commands/CommandObjectTarget.cpp
> lldb/source/Commands/Options.td
> lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
> lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
> lldb/source/Symbol/SymbolContext.cpp
> lldb/source/Target/Target.cpp
> lldb/test/API/commands/target/stop-hooks/TestStopHooks.py
> lldb/test/API/commands/target/stop-hooks/main.c
> lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
> 
> Removed: 
> 
> 
> 
> 
> diff  --git a/lldb/bindings/python/python-swigsafecast.swig 
> b/lldb/bindings/python/python-swigsafecast.swig
> index d5cafbfa67cb..091fc29b1057 100644
> --- a/lldb/bindings/python/python-swigsafecast.swig
> +++ b/lldb/bindings/python/python-swigsafecast.swig
> @@ -152,3 +152,10 @@ SBTypeToSWIGWrapper (lldb::SBSymbolContext* sym_ctx_sb)
>  {
>  return SWIG_NewPointerObj((void *) sym_ctx_sb, 
> SWIGTYPE_p_lldb__SBSymbolContext, 0);
>  }
> +
> +template <>
> +PyObject*
> +SBTypeToSWIGWrapper (lldb::SBStream* stream_sb)
> +{
> +return SWIG_NewPointerObj((void *) stream_sb, SWIGTYPE_p_lldb__SBStream, 
> 0);
> +}
> 
> diff  --git a/lldb/bindings/python/python-wrapper.swig 
> b/lldb/bindings/python/python-wrapper.swig
> index 516590ed5771..c00deba6073b 100644
> --- a/lldb/bindings/python/python-wrapper.swig
> +++ b/lldb/bindings/python/python-wrapper.swig
> @@ -468,6 +468,127 @@ LLDBSwigPythonCallBreakpointResolver
>  return ret_val;
>  }
>  
> +SWIGEXPORT void *
> +LLDBSwigPythonCreateScriptedStopHook
> +(
> +lldb::TargetSP target_sp,
> +const char *python_class_name,
> +const char *session_dictionary_name,
> +lldb_private::StructuredDataImpl *args_impl,
> +Status 
> +)
> +{
> +if (python_class_name == NULL || python_class_name[0] == '\0') {
> +error.SetErrorString("Empty class name.");
> +Py_RETURN_NONE;
> +}
> +if (!session_dictionary_name) {
> +  error.SetErrorString("No session dictionary");
> +  Py_RETURN_NONE;
> +}
> +
> +PyErr_Cleaner py_err_cleaner(true);
> +
> +auto dict = 
> +PythonModule::MainModule().ResolveName(
> +session_dictionary_name);
> +auto pfunc = 
> +PythonObject::ResolveNameWithDictionary(
> +python_class_name, dict);
> +
> +if (!pfunc.IsAllocated()) {
> +error.SetErrorStringWithFormat("Could not find class: %s.", 
> +   python_class_name);
> +return nullptr;
> +}
> +
> +lldb::SBTarget *target_val 
> += new lldb::SBTarget(target_sp);
> +
> +PythonObject target_arg(PyRefType::Owned, 
> SBTypeToSWIGWrapper(target_val));
> +
> +lldb::SBStructuredData *args_value = new 
> lldb::SBStructuredData(args_impl);
> +PythonObject args_arg(PyRefType::Owned, SBTypeToSWIGWrapper(args_value));
> +
> +PythonObject result = pfunc(target_arg, args_arg, dict);
> +
> +if (result.IsAllocated())
> +{
> +// Check that the handle_stop callback is defined:
> +auto callback_func = 
> result.ResolveName("handle_stop");
> +if