[Lldb-commits] [lldb] 9d081a7 - Revert "Make the stop-on-sharedlibrary-events setting work."

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2021-03-19T12:38:41-07:00
New Revision: 9d081a7ffe5c2f9575f77bedd6cbf4385287aeec

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

LOG: Revert "Make the stop-on-sharedlibrary-events setting work."

This reverts commit 9406d43138811ac4dfd0ab31434f65a649bc882e.

I messed up a test, and when I got it right it was failing.  The changed logic
doesn't work quite right (now the async callback called at sync time is
forcing us to stop.  I need to be a little more careful about that.

Added: 


Modified: 
lldb/source/Breakpoint/BreakpointOptions.cpp
lldb/source/Target/StopInfo.cpp

Removed: 
lldb/test/API/functionalities/stop-on-sharedlibrary-load/Makefile

lldb/test/API/functionalities/stop-on-sharedlibrary-load/TestStopOnSharedlibraryEvents.py
lldb/test/API/functionalities/stop-on-sharedlibrary-load/a.cpp
lldb/test/API/functionalities/stop-on-sharedlibrary-load/b.cpp
lldb/test/API/functionalities/stop-on-sharedlibrary-load/main.cpp



diff  --git a/lldb/source/Breakpoint/BreakpointOptions.cpp 
b/lldb/source/Breakpoint/BreakpointOptions.cpp
index 24427835980e..2fdb53e52723 100644
--- a/lldb/source/Breakpoint/BreakpointOptions.cpp
+++ b/lldb/source/Breakpoint/BreakpointOptions.cpp
@@ -453,12 +453,9 @@ bool 
BreakpointOptions::InvokeCallback(StoppointCallbackContext *context,
   : nullptr,
   context, break_id, break_loc_id);
 } else if (IsCallbackSynchronous()) {
-  // If a synchronous callback is called at async time, we will say we
-  // should stop, we're really expression no opinion about stopping, and
-  // the StopInfoBreakpoint::PerformAction will note whether an async
-  // callback had already made a claim to stop or not based on the incoming
-  // values of m_should_stop & m_should_stop_is_valid.
-  return true;
+  // If a synchronous callback is called at async time, it should not say
+  // to stop.
+  return false;
 }
   }
   return true;

diff  --git a/lldb/source/Target/StopInfo.cpp b/lldb/source/Target/StopInfo.cpp
index 1cb582e83cc1..7e830c6e2bed 100644
--- a/lldb/source/Target/StopInfo.cpp
+++ b/lldb/source/Target/StopInfo.cpp
@@ -305,20 +305,6 @@ class StopInfoBreakpoint : public StopInfo {
   // location said we should stop. But that's better than not running
   // all the callbacks.
 
-  // There's one other complication here.  We may have run an async
-  // breakpoint callback that said we should stop.  We only want to
-  // override that if another breakpoint action says we shouldn't 
-  // stop.  If nobody else has an opinion, then we should stop if the
-  // async callback says we should.  An example of this is the async
-  // shared library load notification breakpoint and the setting
-  // stop-on-sharedlibrary-events.
-  // We'll keep the async value in async_should_stop, and track whether
-  // anyone said we should NOT stop in actually_said_continue.
-  bool async_should_stop = false;
-  if (m_should_stop_is_valid)
-async_should_stop = m_should_stop;
-  bool actually_said_continue = false;
-
   m_should_stop = false;
 
   // We don't select threads as we go through them testing breakpoint
@@ -436,10 +422,9 @@ class StopInfoBreakpoint : public StopInfo {
 
 bool precondition_result =
 bp_loc_sp->GetBreakpoint().EvaluatePrecondition(context);
-if (!precondition_result) {
-  actually_said_continue = true;
+if (!precondition_result)
   continue;
-}
+
 // Next run the condition for the breakpoint.  If that says we
 // should stop, then we'll run the callback for the breakpoint.  If
 // the callback says we shouldn't stop that will win.
@@ -477,7 +462,6 @@ class StopInfoBreakpoint : public StopInfo {
   // the condition fails. We've already bumped it by the time
   // we get here, so undo the bump:
   bp_loc_sp->UndoBumpHitCount();
-  actually_said_continue = true;
   continue;
 }
   }
@@ -520,9 +504,6 @@ class StopInfoBreakpoint : public StopInfo {
 
 if (callback_says_stop && auto_continue_says_stop)
   m_should_stop = true;
-else
-  actually_said_continue = true;
-
   
 // If we are going to stop for this breakpoint, then remove the
 // breakpoint.
@@ -536,15 +517,9 @@ class StopInfoBreakpoint : public StopInfo {
 // here.
 if (HasTargetRun

[Lldb-commits] [lldb] e8e07b3 - Revert "Skip all the tests for Windows."

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2021-03-19T12:38:23-07:00
New Revision: e8e07b3a5e6032edeed559db448402094cff31bf

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

LOG: Revert "Skip all the tests for Windows."

This reverts commit a8d62fc8ff1c836e16cfb1a510ee8063ac2652ff.

Added: 


Modified: 

lldb/test/API/functionalities/stop-on-sharedlibrary-load/TestStopOnSharedlibraryEvents.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/stop-on-sharedlibrary-load/TestStopOnSharedlibraryEvents.py
 
b/lldb/test/API/functionalities/stop-on-sharedlibrary-load/TestStopOnSharedlibraryEvents.py
index d19a790f7830..98c4eb89ff54 100644
--- 
a/lldb/test/API/functionalities/stop-on-sharedlibrary-load/TestStopOnSharedlibraryEvents.py
+++ 
b/lldb/test/API/functionalities/stop-on-sharedlibrary-load/TestStopOnSharedlibraryEvents.py
@@ -14,25 +14,16 @@ class TestStopOnSharedlibraryEvents(TestBase):
 def test_stopping_breakpoints(self):
 self.do_test()
 
-@skipIfRemote
-@skipIfWindows
-@no_debug_info_test
 def test_auto_continue(self):
 def auto_continue(bkpt):
 bkpt.SetAutoContinue(True)
 self.do_test(auto_continue)
 
-@skipIfRemote
-@skipIfWindows
-@no_debug_info_test
 def test_failing_condition(self):
 def condition(bkpt):
 bkpt.SetCondition("1 == 2")
 self.do_test(condition)
 
-@skipIfRemote
-@skipIfWindows
-@no_debug_info_test
 def test_continue_callback(self):
 def bkpt_callback(bkpt):
 bkpt.SetScriptCallbackBody("return False")



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

[Lldb-commits] [lldb] a8d62fc - Skip all the tests for Windows.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2021-03-19T12:05:16-07:00
New Revision: a8d62fc8ff1c836e16cfb1a510ee8063ac2652ff

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

LOG: Skip all the tests for Windows.

Added: 


Modified: 

lldb/test/API/functionalities/stop-on-sharedlibrary-load/TestStopOnSharedlibraryEvents.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/stop-on-sharedlibrary-load/TestStopOnSharedlibraryEvents.py
 
b/lldb/test/API/functionalities/stop-on-sharedlibrary-load/TestStopOnSharedlibraryEvents.py
index 98c4eb89ff54..d19a790f7830 100644
--- 
a/lldb/test/API/functionalities/stop-on-sharedlibrary-load/TestStopOnSharedlibraryEvents.py
+++ 
b/lldb/test/API/functionalities/stop-on-sharedlibrary-load/TestStopOnSharedlibraryEvents.py
@@ -14,16 +14,25 @@ class TestStopOnSharedlibraryEvents(TestBase):
 def test_stopping_breakpoints(self):
 self.do_test()
 
+@skipIfRemote
+@skipIfWindows
+@no_debug_info_test
 def test_auto_continue(self):
 def auto_continue(bkpt):
 bkpt.SetAutoContinue(True)
 self.do_test(auto_continue)
 
+@skipIfRemote
+@skipIfWindows
+@no_debug_info_test
 def test_failing_condition(self):
 def condition(bkpt):
 bkpt.SetCondition("1 == 2")
 self.do_test(condition)
 
+@skipIfRemote
+@skipIfWindows
+@no_debug_info_test
 def test_continue_callback(self):
 def bkpt_callback(bkpt):
 bkpt.SetScriptCallbackBody("return False")



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

[Lldb-commits] [lldb] 9406d43 - Make the stop-on-sharedlibrary-events setting work.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2021-03-19T12:02:16-07:00
New Revision: 9406d43138811ac4dfd0ab31434f65a649bc882e

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

LOG: Make the stop-on-sharedlibrary-events setting work.

We weren't taking into account the "m_should_stop" setting that the
synchronous breakpoint callback had already set when we did PerformAction
in the StopInfoBreakpoint.  So we didn't obey its instructions when it
told us to stop.  Fixed that and added some tests both for when we
just have the setting, and when we have the setting AND other breakpoints
at the shared library load notification breakpoint address.

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

Added: 
lldb/test/API/functionalities/stop-on-sharedlibrary-load/Makefile

lldb/test/API/functionalities/stop-on-sharedlibrary-load/TestStopOnSharedlibraryEvents.py
lldb/test/API/functionalities/stop-on-sharedlibrary-load/a.cpp
lldb/test/API/functionalities/stop-on-sharedlibrary-load/b.cpp
lldb/test/API/functionalities/stop-on-sharedlibrary-load/main.cpp

Modified: 
lldb/source/Breakpoint/BreakpointOptions.cpp
lldb/source/Target/StopInfo.cpp

Removed: 




diff  --git a/lldb/source/Breakpoint/BreakpointOptions.cpp 
b/lldb/source/Breakpoint/BreakpointOptions.cpp
index 2fdb53e52723..24427835980e 100644
--- a/lldb/source/Breakpoint/BreakpointOptions.cpp
+++ b/lldb/source/Breakpoint/BreakpointOptions.cpp
@@ -453,9 +453,12 @@ bool 
BreakpointOptions::InvokeCallback(StoppointCallbackContext *context,
   : nullptr,
   context, break_id, break_loc_id);
 } else if (IsCallbackSynchronous()) {
-  // If a synchronous callback is called at async time, it should not say
-  // to stop.
-  return false;
+  // If a synchronous callback is called at async time, we will say we
+  // should stop, we're really expression no opinion about stopping, and
+  // the StopInfoBreakpoint::PerformAction will note whether an async
+  // callback had already made a claim to stop or not based on the incoming
+  // values of m_should_stop & m_should_stop_is_valid.
+  return true;
 }
   }
   return true;

diff  --git a/lldb/source/Target/StopInfo.cpp b/lldb/source/Target/StopInfo.cpp
index 7e830c6e2bed..1cb582e83cc1 100644
--- a/lldb/source/Target/StopInfo.cpp
+++ b/lldb/source/Target/StopInfo.cpp
@@ -305,6 +305,20 @@ class StopInfoBreakpoint : public StopInfo {
   // location said we should stop. But that's better than not running
   // all the callbacks.
 
+  // There's one other complication here.  We may have run an async
+  // breakpoint callback that said we should stop.  We only want to
+  // override that if another breakpoint action says we shouldn't 
+  // stop.  If nobody else has an opinion, then we should stop if the
+  // async callback says we should.  An example of this is the async
+  // shared library load notification breakpoint and the setting
+  // stop-on-sharedlibrary-events.
+  // We'll keep the async value in async_should_stop, and track whether
+  // anyone said we should NOT stop in actually_said_continue.
+  bool async_should_stop = false;
+  if (m_should_stop_is_valid)
+async_should_stop = m_should_stop;
+  bool actually_said_continue = false;
+
   m_should_stop = false;
 
   // We don't select threads as we go through them testing breakpoint
@@ -422,9 +436,10 @@ class StopInfoBreakpoint : public StopInfo {
 
 bool precondition_result =
 bp_loc_sp->GetBreakpoint().EvaluatePrecondition(context);
-if (!precondition_result)
+if (!precondition_result) {
+  actually_said_continue = true;
   continue;
-
+}
 // Next run the condition for the breakpoint.  If that says we
 // should stop, then we'll run the callback for the breakpoint.  If
 // the callback says we shouldn't stop that will win.
@@ -462,6 +477,7 @@ class StopInfoBreakpoint : public StopInfo {
   // the condition fails. We've already bumped it by the time
   // we get here, so undo the bump:
   bp_loc_sp->UndoBumpHitCount();
+  actually_said_continue = true;
   continue;
 }
   }
@@ -504,6 +520,9 @@ class StopInfoBreakpoint : public StopInfo {
 
 if (callback_says_stop && auto_continue_says_stop)
   m_should_stop = true;
+else
+  actually_said_continue = true;
+
   
 // If we are going to stop for

[Lldb-commits] [lldb] 71c4da8 - Don't assume that stepping out of a function will land on the next line.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2021-03-18T17:44:17-07:00
New Revision: 71c4da83b67a485f0cfacbce8b46eaa497df900e

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

LOG: Don't assume that stepping out of a function will land on the next line.

For instance, some recent clang emits this code on x86_64:

0x12b99 <+57>: callq  0x12b40   ; step_out_of_here at 
main.cpp:11
->  0x12b9e <+62>: xorl   %eax, %eax
0x12ba0 <+64>: popq   %rbp
0x12ba1 <+65>: retq

and the "xorl %eax, %eax" is attributed to the same line as the callq.  Since
step out is supposed to stop just on returning from the function, you can't 
guarantee
it will end up on the next line.  I changed the test to check that we were 
either
on the call line or on the next line, since either would be right depending on 
the
debug information.

Added: 


Modified: 
lldb/test/API/functionalities/thread/step_out/TestThreadStepOut.py
lldb/test/API/functionalities/thread/step_out/main.cpp

Removed: 




diff  --git 
a/lldb/test/API/functionalities/thread/step_out/TestThreadStepOut.py 
b/lldb/test/API/functionalities/thread/step_out/TestThreadStepOut.py
index 2ab36b57eaee..5b34e74b410d 100644
--- a/lldb/test/API/functionalities/thread/step_out/TestThreadStepOut.py
+++ b/lldb/test/API/functionalities/thread/step_out/TestThreadStepOut.py
@@ -62,50 +62,58 @@ def test_python(self):
 """Test thread step out on one thread via Python API (dwarf)."""
 self.build(dictionary=self.getBuildFlags())
 self.step_out_test(self.step_out_with_python)
-
+
 def setUp(self):
 # Call super's setUp().
 TestBase.setUp(self)
 # Find the line number for our breakpoint.
 self.bkpt_string = '// Set breakpoint here'
 self.breakpoint = line_number('main.cpp', self.bkpt_string)   
-
-self.step_out_destination = line_number(
- 'main.cpp', '// Expect to stop here after step-out.')
-
+self.step_in_line = line_number('main.cpp', '// But we might still be 
here')
+self.step_out_dest = line_number('main.cpp', '// Expect to stop here 
after step-out.')
+
+def check_stepping_thread(self):
+zeroth_frame = self.step_out_thread.frames[0]
+line_entry = zeroth_frame.line_entry
+self.assertTrue(line_entry.IsValid(), "Stopped at a valid line entry")
+self.assertEqual("main.cpp", line_entry.file.basename, "Still in 
main.cpp")
+# We can't really tell whether we stay on our line
+# or get to the next line, it depends on whether there are any
+# instructions between the call and the return.
+line = line_entry.line
+self.assertTrue(line == self.step_out_dest or line == 
self.step_in_line, "Stepped to the wrong line: {0}".format(line))
+
 def step_out_single_thread_with_cmd(self):
+other_threads = {}
+for thread in self.process.threads:
+if thread.GetIndexID() == self.step_out_thread.GetIndexID():
+continue
+other_threads[thread.GetIndexID()] = thread.frames[0].line_entry
+
+# There should be other threads...
+self.assertNotEqual(len(other_threads), 0)
 self.step_out_with_cmd("this-thread")
-self.expect(
-"thread backtrace all",
-"Thread location after step out is correct",
-substrs=[
-"main.cpp:%d" %
-self.step_out_destination,
-"main.cpp:%d" %
-self.breakpoint])
+# The other threads should not have made progress:
+for thread in self.process.threads:
+index_id = thread.GetIndexID()
+line_entry = other_threads.get(index_id)
+if line_entry:
+self.assertEqual(thread.frames[0].line_entry.file.basename, 
line_entry.file.basename, "Thread {0} moved by file".format(index_id))
+self.assertEqual(thread.frames[0].line_entry.line, 
line_entry.line, "Thread {0} moved by line".format(index_id))
 
 def step_out_all_threads_with_cmd(self):
 self.step_out_with_cmd("all-threads")
-self.expect(
-"thread backtrace all",
-"Thread location after step out is correct",
-substrs=[
-"main.cpp:%d" %
-self.step_out_destination])
-
+
 def step_out_with_cmd(self, run_mode):
 self.runCmd("thread select %d" % self.step_out_thread.GetIndexID())
 self.runCmd("thread step-out -m %s" % run_mode)
 self.expect("process status", "Expected stop reason to be step-out",
 substrs=["stop reason = step out"])
 
-self.expect(
-   

[Lldb-commits] [lldb] 483ec13 - Use internal_dict everywhere we refer to the python session dict in docs.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2021-02-09T17:48:47-08:00
New Revision: 483ec136da7193de781a5284f1c37929cc27c05c

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

LOG: Use internal_dict everywhere we refer to the python session dict in docs.

Added: 


Modified: 
lldb/docs/use/python-reference.rst
lldb/source/Commands/CommandObjectBreakpointCommand.cpp

Removed: 




diff  --git a/lldb/docs/use/python-reference.rst 
b/lldb/docs/use/python-reference.rst
index f3ce744128c9..a1bdc87ab912 100644
--- a/lldb/docs/use/python-reference.rst
+++ b/lldb/docs/use/python-reference.rst
@@ -179,35 +179,35 @@ arguments:
 
 ::
 
-  def breakpoint_function_wrapper(frame, bp_loc, dict):
+  def breakpoint_function_wrapper(frame, bp_loc, internal_dict):
  # Your code goes here
 
 or:
 
 ::
 
-  def breakpoint_function_wrapper(frame, bp_loc, extra_args, dict):
+  def breakpoint_function_wrapper(frame, bp_loc, extra_args, internal_dict):
  # Your code goes here
 
 
-++---+---+
-| Argument   | Type  | Description 

  |
-++---+---+
-| **frame**  | **lldb.SBFrame**  | The current stack frame 
where the breakpoint got hit.   
  |
-||   | The object will always be 
valid.  
|
-||   | This **frame** argument 
might *not* match the currently selected stack frame found in the **lldb** 
module global variable **lldb.frame**. |
-++---+---+
-| **bp_loc** | **lldb.SBBreakpointLocation** | The breakpoint location 
that just got hit. Breakpoints are represented by **lldb.SBBreakpoint** 
  |
-||   | objects. These breakpoint 
objects can have one or more locations. These locations 
|
-||   | are represented by 
**lldb.SBBreakpointLocation** objects.  
   |
-++---+---+
-| **extra_args** | **lldb.SBStructuredData** | **Optional** If your 
breakpoint callback function takes this extra parameter, then when the callback 
gets added to a breakpoint, its  |
-||   | contents can parametrize 
this use of the callback.  For instance, instead of writing a callback that 
stops when the caller is "Foo",  |
-||   | you could take the function 
name from a field in the **extra_args**, making the callback more general.  The 
**-k** and **-v** options |
-||   | to **breakpoint command 
add** will be passed as a Dictionary in the **extra_args** parameter, or you 
can provide it with the SB API's.|
-++---+---+
-| **dict**   | **dict**  | The python session 
dictionary as a standard python dictionary object.  
   |
-++---+---+
++---+---+---+
+| Argument  | Type  | Description  

[Lldb-commits] [lldb] ffd7be6 - Remove trailing spaces after \ in comments.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2021-02-09T16:06:47-08:00
New Revision: ffd7be65d0efbe8448b8fa051ad213be51e8c367

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

LOG: Remove trailing spaces after \ in comments.

Added: 


Modified: 
lldb/source/Commands/CommandObjectBreakpointCommand.cpp

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectBreakpointCommand.cpp 
b/lldb/source/Commands/CommandObjectBreakpointCommand.cpp
index 241a75e7fbb2..1b2149525d80 100644
--- a/lldb/source/Commands/CommandObjectBreakpointCommand.cpp
+++ b/lldb/source/Commands/CommandObjectBreakpointCommand.cpp
@@ -129,9 +129,9 @@ def breakpoint_callback(frame, bp_loc, extra_args, dict):
 
 )"
 "The arguments are the same as the arguments passed to generated 
functions as \
-described above.  In the second form, any -k and -v pairs provided to the 
command will \ 
+described above.  In the second form, any -k and -v pairs provided to the 
command will \
 be packaged into a SBDictionary in an SBStructuredData and passed as the 
extra_args parameter. \
-\n\n\  
+\n\n\
 Note that the global variable 'lldb.frame' will NOT be updated when \
 this function is called, so be sure to use the 'frame' argument. The 'frame' 
argument \
 can get you to the thread via frame.GetThread(), the thread can get you to the 
\



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

[Lldb-commits] [lldb] 365b186 - Add documentation for the extra_args parameter to breakpoint commands.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2021-02-09T15:33:36-08:00
New Revision: 365b186c242b0c3516d7dbb174f3a258c1c8361c

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

LOG: Add documentation for the extra_args parameter to breakpoint commands.

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

Added: 


Modified: 
lldb/docs/use/python-reference.rst
lldb/source/Commands/CommandObjectBreakpointCommand.cpp

Removed: 




diff  --git a/lldb/docs/use/python-reference.rst 
b/lldb/docs/use/python-reference.rst
index e5542bb5b0ae..f3ce744128c9 100644
--- a/lldb/docs/use/python-reference.rst
+++ b/lldb/docs/use/python-reference.rst
@@ -182,20 +182,32 @@ arguments:
   def breakpoint_function_wrapper(frame, bp_loc, dict):
  # Your code goes here
 
+or:
 
-++---+---+
-| Argument   | Type  | Description 

  |
-++---+---+
-| **frame**  | **lldb.SBFrame**  | The current stack frame where 
the breakpoint got hit. 
|
-||   | The object will always be 
valid.  
|
-||   | This **frame** argument might 
*not* match the currently selected stack frame found in the **lldb** module 
global variable **lldb.frame**. |
-++---+---+
-| **bp_loc** | **lldb.SBBreakpointLocation** | The breakpoint location that 
just got hit. Breakpoints are represented by **lldb.SBBreakpoint**  
 |
-||   | objects. These breakpoint 
objects can have one or more locations. These locations 
|
-||   | are represented by 
**lldb.SBBreakpointLocation** objects.  
   |
-++---+---+
-| **dict**   | **dict**  | The python session dictionary 
as a standard python dictionary object. 
|
-++---+---+
+::
+
+  def breakpoint_function_wrapper(frame, bp_loc, extra_args, dict):
+ # Your code goes here
+
+
+++---+---+
+| Argument   | Type  | Description 

  |
+++---+---+
+| **frame**  | **lldb.SBFrame**  | The current stack frame 
where the breakpoint got hit.   
  |
+||   | The object will always be 
valid.  
|
+||   | This **frame** argument 
might *not* match the currently selected stack frame found in the **lldb** 
module global variable **lldb.frame**. |
+++---+---+
+| **bp_loc** | **lldb.SBBreakpointLocation** | The breakpoint location 
that just got 

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

[Jim Ingham via lldb-commits]

> On Jan 24, 2021, at 8:30 PM, David Blaikie  wrote:
> 
> I guess lldb doesn't have a machine readable form, like gdb's machine 
> interface that might make for a more robust thing to test against most of the 
> time (& then leaving a limited number of tests that test the user-textual 
> output)? Instead the python API is the machine interface? 

That was the original idea, except that we also tried to make it easy to test 
command line output in the same tests that test the API's.  Really the only 
part of the system the API tests aren't great at is stuff that depends on 
mid-command interactivity (prompts, line-editing interactions, the REPL, stuff 
like that).  The difference between the two to my mind is pretty much that the 
Shell tests don't require you to know Python, or learn the SB API's to write 
tests.

>  
> Another aspect of end-to-endness is being able to test a specific 
> component of lldb, instead of just the debugger as a whole. Here the API 
> tests cannot help because the "API" is the lldb public API.
> 
> Not sure I followed here - you mean the API tests aren't more narrowly 
> targeted than the Shell tests, because the API is the public API, so it's 
> mostly/pretty close to what you can interact with from the Shell anyway - 
> doesn't give you lower-level access akin to unit testing? Fair enough.
>  

Yes, this is particularly true for lldb's plugins.  There isn't any really 
compelling reason for an lldb user to know the details of how DWARF was 
ingested.  At that level, lldb should present the data from the generic Symbol 
interface, not how it came from DWARF.  So if you want to test the DWARF parser 
specifically then UnitTests are the way to go.  And for testing utility classes 
which don't require lots of other subsystems to construct themselves, the 
UnitTests are much easier to write.  These also are easy to migrate as code 
changes because we know how to do "I added a parameter to an API, go fix the 
calling code" pretty well.

My take is that API tests will always be more precise because each time you get 
a bit of data that you want to test against you get only that data, you don't 
get it intermixed with other text that you have to decide how to either capture 
(and maybe end up testing things you didn't intend to test) or run the risk 
that the patterns you were using to grab the data you thought you were testing 
actually grabbed a different part of the command text.  The solution to that if 
you wanted to do more rigorous tests from the command line is to write special 
purpose commands that present output in a form that's not good for users but is 
better structured for testing.  But that seems like wasted effort and support 
burden when the API's to get what you want are right there in front of you...

Jim


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

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

[Jim Ingham via lldb-commits]

lldb creates a single line table out of the debug_line input and the 
inlined_subroutine info from the debug_info.  For instance, if you have a 
nested set of inlines that all have the same start address, they cannot be 
represented in the debug_line which requires monotonically increasing 
addresses.  But when you are "stepping" into the set of nested inlines, lldb 
would like to represent the step as first stopping before the call in the outer 
function, then stepping one by one into the nested inlines.  I don't know why 
exactly DWARF line tables need to be monotonically increasing in address, but 
we couldn't see any good reason why lldb should also have to do this little 
two-step every time we tried to figure out where you are, we decided to merge 
the info up front.

You could still write Unit Tests accessing the lldb line table construction 
rather than the DWARF debug_line ingestion.  But IIRC the layer between the 
LineEntries in lldb_private and the classes in the SB API is pretty thin, so 
there's less motivation to test that way.

Jim


> On Jan 24, 2021, at 8:32 PM, David Blaikie  wrote:
> 
> 
> 
> On Fri, Jan 22, 2021 at 9:42 AM Jim Ingham  wrote:
> If you are just loading an object file and the looking at the line table or 
> something like that, would a UnitTest be more suitable?
> 
> Maybe, though for what it's worth, this isn't an issue with the line table 
> (well, not the .debug_line contents) as such - this is testing a change to 
> .debug_info - specifically, the use of DW_AT_ranges on a DW_TAG_subprogram. 
> But it manifested as breakpoints not having source information. I don't know 
> a great deal about how the line table ended up interacting with the address 
> ranges specified on the DW_TAG_subprogram, but it did in some way.
> 
> Not sure if that is or isn't especially amenable to unit testing given the 
> LLDB architecture of these components.
> 
> - Dave
>  
> 
> Jim
> 
> 
> > On Jan 22, 2021, at 5:37 AM, Pavel Labath  wrote:
> > 
> > On 19/01/2021 23:23, David Blaikie wrote:
> >> On Tue, Jan 19, 2021 at 1:12 AM Pavel Labath  wrote:
> >> Yeah - I have mixed feelings about debugger testing here - it is nice
> >> to have end-to-end tests which makes for handy debugger testing
> >> (though I guess in theory, debuginfo-tests is the place for
> >> intentional end-to-end testing), though also being able to test
> >> different features (DWARF version, split DWARF, dsym V object
> >> debugging, etc) when they're written as end-to-end tests.
> > 
> > Yeah, it would be nice if there was a clearer separation between the two 
> > categories. The current setup has evolved organically, as the end-to-end 
> > API tests used to be the only kinds of tests.
> > 
> > 
> >> Can we write non-end-to-end API tests, then?
> > 
> > Kind of. There is no fundamental reason why one couldn't run llvm-mc or 
> > whatever as a part of an API test. The main issue is that we don't have the 
> > infrastructure for that set up right now. I think the reason for that is 
> > that once you start dealing with "incomplete" executables which cannot be 
> > run on the host platform, the usefulness of interactivity goes down 
> > sharply. It is hard for such a test to do something other than load up some 
> > executable and query its state. This is a perfect use case for a shell test.
> > 
> > There are exceptions though. For example we have a collection of "API" 
> > tests which test the gdb-remote communication layer, by mocking one end of 
> > the connection. Such tests are necessarily interactive, which is why they 
> > ended up in the API category, but they are definitely not end-to-end tests, 
> > and they either don't use any executables, or just use a static yaml2objed 
> > executable. This is why our API tests have the ability to run yaml2obj and 
> > one could add other llvm tools in a similar fashion.
> > 
> > Another aspect of end-to-endness is being able to test a specific component 
> > of lldb, instead of just the debugger as a whole. Here the API tests cannot 
> > help because the "API" is the lldb public API. However, there are also 
> > various tricks you can do by using the low-level (debugging) commands (like 
> > the "image lookup" thing I mentioned) to interact with the lower debugger 
> > layers in some manner.
> > 
> > 
> > pl
> 

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

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

[Jim Ingham via lldb-commits]

If you are just loading an object file and the looking at the line table or 
something like that, would a UnitTest be more suitable?

Jim


> On Jan 22, 2021, at 5:37 AM, Pavel Labath  wrote:
> 
> On 19/01/2021 23:23, David Blaikie wrote:
>> On Tue, Jan 19, 2021 at 1:12 AM Pavel Labath  wrote:
>> Yeah - I have mixed feelings about debugger testing here - it is nice
>> to have end-to-end tests which makes for handy debugger testing
>> (though I guess in theory, debuginfo-tests is the place for
>> intentional end-to-end testing), though also being able to test
>> different features (DWARF version, split DWARF, dsym V object
>> debugging, etc) when they're written as end-to-end tests.
> 
> Yeah, it would be nice if there was a clearer separation between the two 
> categories. The current setup has evolved organically, as the end-to-end API 
> tests used to be the only kinds of tests.
> 
> 
>> Can we write non-end-to-end API tests, then?
> 
> Kind of. There is no fundamental reason why one couldn't run llvm-mc or 
> whatever as a part of an API test. The main issue is that we don't have the 
> infrastructure for that set up right now. I think the reason for that is that 
> once you start dealing with "incomplete" executables which cannot be run on 
> the host platform, the usefulness of interactivity goes down sharply. It is 
> hard for such a test to do something other than load up some executable and 
> query its state. This is a perfect use case for a shell test.
> 
> There are exceptions though. For example we have a collection of "API" tests 
> which test the gdb-remote communication layer, by mocking one end of the 
> connection. Such tests are necessarily interactive, which is why they ended 
> up in the API category, but they are definitely not end-to-end tests, and 
> they either don't use any executables, or just use a static yaml2objed 
> executable. This is why our API tests have the ability to run yaml2obj and 
> one could add other llvm tools in a similar fashion.
> 
> Another aspect of end-to-endness is being able to test a specific component 
> of lldb, instead of just the debugger as a whole. Here the API tests cannot 
> help because the "API" is the lldb public API. However, there are also 
> various tricks you can do by using the low-level (debugging) commands (like 
> the "image lookup" thing I mentioned) to interact with the lower debugger 
> layers in some manner.
> 
> 
> pl

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

Re: [Lldb-commits] [PATCH] D93874: [process] fix exec support on Linux

[Jim Ingham via lldb-commits]

Excellent, thanks for persisting on this!

I think your second idea sounds less error prone than having to figure out 
whether the cache is trustworthy at a particular point.  Maybe even better than 
triggering off a stop event is to clear the caches before we do whatever might 
make the threads in the cache invalid.  That should only happen in 
Process::UpdateThreadList, so we could just move the current virtual 
UpdateThreadList method -> DoUpdateThreadList, and add a non-virtual 
UpdateThreadList that clears the cache and then calls UpdateThreadList.

There's also a non-virtual UpdateThreadListIfNeeded, and we could do it there 
before calling the virtual UpdateThreadList.  But then we'd have to ensure that 
the only way to call UpdateThreadList if through UpdateThreadListIfNeeded, 
which seems hard to ensure formally.  So I think just wrapping the virtual 
method to clear the cache before updating the thread list is the most robust 
way to do this.


Jim

> On Jan 22, 2021, at 8:53 AM, walter erquinigo via Phabricator 
>  wrote:
> 
> wallace added a comment.
> 
> Jim, thanks for the pointers! I think we are getting close to the issue. 
> After doing what you asked, I found out the following:
> 
> - I set up the state of the lldb debugging the program that will exec right 
> before it execs
> - Then I do "continue"
> - ThreadPlan::WillResume is invoked, which effectively clears out the 
> m_thread cache. After this, I would expect no calls to ThreadPlan::GetThread 
> until the the new thread list is created
> - Then suddenly ThreadList::ShouldReportRun is invoked, which is handling the 
> resume event. It eventually asks the current ThreadPlan ShouldReportRun, 
> which invokes GetPreviousPlan() if m_run_vote is eVoteNoOpinion
> 
>  Vote ThreadPlan::ShouldReportRun(Event *event_ptr) {
>if (m_run_vote == eVoteNoOpinion) {
>  ThreadPlan *prev_plan = GetPreviousPlan();
>  if (prev_plan)
>return prev_plan->ShouldReportRun(event_ptr);
>}
>return m_run_vote;
>  }
> 
> This triggers ends up invoking GetThread()
> 
>  ThreadPlan *GetPreviousPlan() { return GetThread().GetPreviousPlan(this); }
> 
> Which causes the incorrect value to be cached.
> 
> - After this event is processed, the stop exec happens, but the 
> ThreadPlanBase's m_thread cache is not null, which breaks the invariant that 
> you mentioned
> 
>> Keep continuing in the inferior lldb if you have to till you see it get the 
>> stop packet that corresponds to the exec. At this point all the thread plans 
>> should have no cached threads, so they are going to have to look them up.
> 
> I think that the ShouldReportRun is unavoidable at that step, so I thought of 
> a couple of solutions.
> 
> - One is to to modify GetPreviousPlan() to something like this
> 
>  ThreadPlan *GetPreviousPlan() { return GetThread(/*cache_thread*/ 
> false).GetPreviousPlan(this); }
> 
> This allows traversing the thread plan stack without caching the thread. This 
> might be fine because ShouldReportRun is merely looking for any thread plan 
> in the stack with an m_run_vote other than eVoteNoOpinion. It doesn't use the 
> thread for any other reason.
> 
> - Another solution is to force clear the m_thread caches in all the 
> ThreadPlans as soon as there's a stop event.
> 
> What do you think?
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D93874/new/
> 
> https://reviews.llvm.org/D93874
> 

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

Re: [Lldb-commits] [PATCH] D93874: [process] fix exec support on Linux

[Jim Ingham via lldb-commits]

The ThreadPlanStack always has one base thread plan.  You can't get rid of that 
one, the system relies on its always being there.  Despite it's name, 
DiscardThreadPlans doesn't actually discard all the thread plans, just all but 
the base thread plan...  So I think that's neither here nor there...

The thing I want to see is the sequence of the events "Make the new thread list 
after stopping for exec" and "Call ThreadPlan::GetThread()" the first time 
after the stop for the exec where we go from no cached thread to caching the 
thread from the old thread list.

The former is ProcessGDBRemote::UpdateThreadList.

You can figure out the latter by running the debugger on an lldb that is 
debugging a program that exec's.  Have the inferior lldb drive its inferior to 
the state just before the exec.  In the superior lldb, set a breakpoint on 
ThreadPlan::GetThread().  Keep continuing in the inferior lldb if you have to 
till you see it get the stop packet that corresponds to the exec.  At this 
point all the thread plans should have no cached threads, so they are going to 
have to look them up.  Keep going from there to the first time that 
ThreadPlan::GetThread is called and has to look up the thread with 
FindThreadByID call.  If I understand what you are describing, that first call 
should pull up the old thread pointer and cache it.  

If that happens before the call to ProcessGDBRemote::UpdateThreadList finishes 
that would be bad, and we have to stop it doing that.  If what's going on is 
that we set up the new thread list, broadcast the event, and then change the 
thread list again in response to detecting that this is an exec, that would 
also be bad.  We really should have a finalized thread list for the stop before 
we start trying to figure out what to do with the stop.


Jim


 

> On Jan 21, 2021, at 4:28 PM, Walter  wrote:
> 
> I've tried to find a way to move the calls the way you mentioned, but it 
> doesn't seem trivial.
> 
> Some more information:
> - The invocation to the thread plan is done by Thread::ShouldStop, where it 
> does
> 
> ```
> // We're starting from the base plan, so just let it decide;
> if (current_plan->IsBasePlan()) {
>   should_stop = current_plan->ShouldStop(event_ptr);
> ```
> 
> The interesting part of this call-stack starts at 
> Process::HandlePrivateEvent, which seems to be handling the Stop Event. Where 
> I think there's some inconsistent code is in ThreadPlanBase::ShouldStop, 
> because it tries to get the stop reason, which fails for Linux, and then it 
> processes eStopReasonExec a few lines below. And see what it does:
> 
> ```
>   case eStopReasonExec:
>   // If we crashed, discard thread plans and stop.  Don't force the
>   // discard, however, since on rerun the target may clean up this
>   // exception and continue normally from there.
>   LLDB_LOGF(
>   log,
>   "Base plan discarding thread plans for thread tid = 0x%4.4" PRIx64
>   " (exec.)",
>   m_tid);
>   GetThread().DiscardThreadPlans(false);
>   return true;
> ```
> 
> It does discard the thread plans for that thread! This makes me believe that 
> it should be fine to delete the thread plans in the first place. I wasn't 
> able to figure out more, but I can dig deeper if you give me a few pointers. 
> In any case, this last code of block makes me believe that deleting the 
> thread plans or reseting the thread pointer in the base thread plan might be 
> fine.
> 
> 
> Btw, this is a bunch of logs I got, which start at a breakpoint, then there's 
> a "continue", which triggers what I'm saying. The backtrace is below
> 
> (lldb) bt
> * thread #1, name = 'runner', stop reason = instruction step into
>   * frame #0: 0x7f1fe674838d libc.so.6`raise + 61
> frame #1: 0x00400a3c runner`main(argc=2, argv=0x7fff4b78fc08) 
> at runner.cpp:20
> frame #2: 0x7f1fe6734555 libc.so.6`__libc_start_main + 245
> frame #3: 0x00400919 runner`_start + 41
> (lldb) thread plan list /// See that only 
> the base plan is there
> thread #1: tid = 0x2b72f1:
>   Active plan stack:
> Element 0: Base thread plan.
>   Completed plan stack:
> Element 0: Stepping one instruction past 0x7f1fe6748387 stepping into 
> calls
> Element 1: Stepping one instruction past 0x7f1fe6748387 stepping into 
> calls
> (lldb) c
> lldb Process::Resume -- locking run lock
> lldb Process::PrivateResume() m_stop_id = 3, public state: 
> stopped private state: stopped
> lldb WillResume Thread #1 (0x0x7fcd3da0): tid = 0x2b72f1, pc 
> = 0x7f1fe674838d, sp = 0x7fff4b78fad8, fp = 0x7fff4b78fb20, plan = 'base 
> plan', state = running, stop others = 0
> lldb Resuming thread: 2b72f1 with state: running.
> lldb 0x4e7020 Listener::Listener('gdb-remote.resume-packet-sent')
> lldb 0x4e7020 Listener::StartListeningForEvents (broadcaste

Re: [Lldb-commits] [PATCH] D93874: [process] fix exec support on Linux

[Jim Ingham via lldb-commits]

> On Jan 21, 2021, at 2:33 PM, Jim Ingham  wrote:
> 
> 
> 
>> On Jan 21, 2021, at 12:51 PM, walter erquinigo via Phabricator 
>>  wrote:
>> 
>> wallace added a comment.
>> 
>> Sorry for returning late to this diff, but I have some additional 
>> information. This is what's happening:
>> 
>> - Before the exec, the base thread plan holds a reference to the thread 
>> pointer
>> - During the exec, the original thread is destroyed in 
>> ProcessGDBRemote::SetLastStopPacket, and later a new Thread pointer is 
>> created for the same tid. Notice that the base thread plan is still holding 
>> a reference to the previous pointer even though there's a new Thread pointer 
>> for the same tid. On Linux, exec preserves the tid. This step is where I 
>> think there's a wrong invariant.
>> - Then, at some point, the base thread plan is asked its stop reason, and 
>> it'll try to use the destroyed pointer, thus crashing.
> 
> Thanks for looking at this some more.
> 
> Sadly, I think I'm still missing something.  Here's how I think things should 
> happen:
> 
> 1) The program was stopped somewhere in the original program (before exec), 
> and the user continued the process
>   a) WillResume is called and all the thread plans clear their cached thread 
> pointers.  So they will have to look them up by ID when next asked a question.
>   b) Then the process resumes.
> 2) We get a stop packet with a reason of "exec" from the stub.
>   a) We process the stop packet, and get the new thread list
>   b) We start to build the new thread list

Ack, that was confusing.  Item b) should be "We start to build the new 
ThreadList".  The object in a) is the thread list the stub tells about, either 
in the stop packet or through subsequent queries.  The object in b) is the 
ThreadList in the Process that will describe the state at this particular stop 
point.

>  1) From what you are saying, in the case of exec, regardless of whether 
> the TID matches an extant one or not, we make a new Thread *, put it into the 
> new ThreadList and delete the old Thread *.
>   c) Then we start figuring out what to do after the stop.
>  i) If the TID of the new thread is the same as any of the TID's in the 
> old thread list (and thus of the ThreadPlanStack that was managing it) when 
> the new thread gets asked what to do, it will route the question to the 
> ThreadPlanStack for that TID.
>  ii) If this happens after the new thread list is in place, 
> FindThreadByID will return the new, valid thread, and there should be no 
> problem.
> 
> So for this to fail as you described, somewhere between the time that we 
> stopped for exec and the time we finalized the new thread list and discarded 
> the old threads, somebody must have asked the thread plan stack for that TID 
> a question that triggered it to cache the old thread's Thread *.
> 
> That really shouldn't happen, precisely for the reason you see here.  When we 
> stop, we have to finish setting up the current ThreadList before we start 
> asking questions of the ThreadPlanStack for threads, like ShouldStop or 
> whatever.  It makes no sense to ask the pre-stop thread list questions for 
> the current stop, and we shouldn't do it.
> 
> Do you know where we're calling ThreadPlan::GetThread while the thread list 
> still has the old threads in it?  I'd really like to stop that if we can.  
> And if you can move those queries till after the new thread list is 
> established, then we shouldn't need any of the alternatives you suggest.
> 
> About the alternatives:
> 
> First one: I'd rather not artificially clear out the ThreadPlanStack after 
> exec.  After all, if you knew that exec on Linux preserves the TID, you could 
> write a thread plan that carried over the exec and did something interesting. 
>  Be a shame to prevent that for implementation reasons.
> 
> Second one: Adding the IsValid check won't do any harm, but it implicitly 
> lets something happen that I don't think should happen, so it doesn't feel 
> right...
> 
> Third one: If there's some good reason why you have to first check through 
> the old thread list for stop reasons, then update the thread list, then ask 
> again with no Resume in between, I think the cleanest solution is to announce 
> that by explicitly clearing the ThreadPlans' cached thread pointer.  So I 
> think this one's the best option.  But again, I'd like to understand why it 
> was necessary.
> 
> Jim
> 
> 
>> 
>> I've found three possible fixes for this (I'm pretty sure that you can come 
>> up with more):
>> 
>> - The first one is what this diff does, which is clearing all the thread 
>> plans once the gdbremote client knows there's an exec.
>> - The second one is modifying the ThreadPlan::GetThread method, which 
>> currently looks like this
>> 
>> if (m_thread)
>> return *m_thread;
>> 
>>   ThreadSP thread_sp = m_process.GetThreadList().FindThreadByID(m_tid);
>>   m_thread = thread_sp.get();
>>   return *m_thread;
>> 
>> Changing it into
>> 

Re: [Lldb-commits] [PATCH] D93874: [process] fix exec support on Linux

[Jim Ingham via lldb-commits]

> On Jan 21, 2021, at 12:51 PM, walter erquinigo via Phabricator 
>  wrote:
> 
> wallace added a comment.
> 
> Sorry for returning late to this diff, but I have some additional 
> information. This is what's happening:
> 
> - Before the exec, the base thread plan holds a reference to the thread 
> pointer
> - During the exec, the original thread is destroyed in 
> ProcessGDBRemote::SetLastStopPacket, and later a new Thread pointer is 
> created for the same tid. Notice that the base thread plan is still holding a 
> reference to the previous pointer even though there's a new Thread pointer 
> for the same tid. On Linux, exec preserves the tid. This step is where I 
> think there's a wrong invariant.
> - Then, at some point, the base thread plan is asked its stop reason, and 
> it'll try to use the destroyed pointer, thus crashing.

Thanks for looking at this some more.

Sadly, I think I'm still missing something.  Here's how I think things should 
happen:

1) The program was stopped somewhere in the original program (before exec), and 
the user continued the process
   a) WillResume is called and all the thread plans clear their cached thread 
pointers.  So they will have to look them up by ID when next asked a question.
   b) Then the process resumes.
2) We get a stop packet with a reason of "exec" from the stub.
   a) We process the stop packet, and get the new thread list
   b) We start to build the new thread list
  1) From what you are saying, in the case of exec, regardless of whether 
the TID matches an extant one or not, we make a new Thread *, put it into the 
new ThreadList and delete the old Thread *.
   c) Then we start figuring out what to do after the stop.
  i) If the TID of the new thread is the same as any of the TID's in the 
old thread list (and thus of the ThreadPlanStack that was managing it) when the 
new thread gets asked what to do, it will route the question to the 
ThreadPlanStack for that TID.
  ii) If this happens after the new thread list is in place, FindThreadByID 
will return the new, valid thread, and there should be no problem.

So for this to fail as you described, somewhere between the time that we 
stopped for exec and the time we finalized the new thread list and discarded 
the old threads, somebody must have asked the thread plan stack for that TID a 
question that triggered it to cache the old thread's Thread *.

That really shouldn't happen, precisely for the reason you see here.  When we 
stop, we have to finish setting up the current ThreadList before we start 
asking questions of the ThreadPlanStack for threads, like ShouldStop or 
whatever.  It makes no sense to ask the pre-stop thread list questions for the 
current stop, and we shouldn't do it.

Do you know where we're calling ThreadPlan::GetThread while the thread list 
still has the old threads in it?  I'd really like to stop that if we can.  And 
if you can move those queries till after the new thread list is established, 
then we shouldn't need any of the alternatives you suggest.

About the alternatives:

First one: I'd rather not artificially clear out the ThreadPlanStack after 
exec.  After all, if you knew that exec on Linux preserves the TID, you could 
write a thread plan that carried over the exec and did something interesting.  
Be a shame to prevent that for implementation reasons.

Second one: Adding the IsValid check won't do any harm, but it implicitly lets 
something happen that I don't think should happen, so it doesn't feel right...

Third one: If there's some good reason why you have to first check through the 
old thread list for stop reasons, then update the thread list, then ask again 
with no Resume in between, I think the cleanest solution is to announce that by 
explicitly clearing the ThreadPlans' cached thread pointer.  So I think this 
one's the best option.  But again, I'd like to understand why it was necessary.

Jim


> 
> I've found three possible fixes for this (I'm pretty sure that you can come 
> up with more):
> 
> - The first one is what this diff does, which is clearing all the thread 
> plans once the gdbremote client knows there's an exec.
> - The second one is modifying the ThreadPlan::GetThread method, which 
> currently looks like this
> 
>  if (m_thread)
>  return *m_thread;
> 
>ThreadSP thread_sp = m_process.GetThreadList().FindThreadByID(m_tid);
>m_thread = thread_sp.get();
>return *m_thread;
> 
> Changing it into
> 
>  if (m_thread && m_thread->IsValid()) // IsValid will return false for a 
> deleted thread
>  return *m_thread;
> 
>ThreadSP thread_sp = m_process.GetThreadList().FindThreadByID(m_tid);
>m_thread = thread_sp.get();
>return *m_thread;
> 
> also works, as it will make the ThreadPlan grab the new thread pointer.
> 
> - Another solution is to create a method ThreadPlan::PrepareForExec() which 
> just clears the m_thread pointer in the the thread plan, and call it from 
> ProcessGDBRemote::SetLastStopPacket, 

[Lldb-commits] [lldb] 98feb08 - Use CXX_SOURCES and point to the right source file.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2021-01-20T18:38:07-08:00
New Revision: 98feb08e449f179c3c5ccc6878c31cf16c160b06

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

LOG: Use CXX_SOURCES and point to the right source file.

Copy paste error, but the test still built on macOS.  Weird.
It failed on debian linux with an error about -fno-limit-debug-info
not being a supported flag???  Not sure how this goof would cause
that error, but let's see if it did...

Added: 


Modified: 
lldb/test/API/lang/cpp/break-on-initializers/Makefile

Removed: 




diff  --git a/lldb/test/API/lang/cpp/break-on-initializers/Makefile 
b/lldb/test/API/lang/cpp/break-on-initializers/Makefile
index 7714f26e52bc..e78030cbf752 100644
--- a/lldb/test/API/lang/cpp/break-on-initializers/Makefile
+++ b/lldb/test/API/lang/cpp/break-on-initializers/Makefile
@@ -1,4 +1,4 @@
-C_SOURCES := main.c
+CXX_SOURCES := main.cpp
 CXXFLAGS_EXTRAS := -std=c++11
 
 include Makefile.rules



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

[Lldb-commits] [lldb] bff3891 - Fix a bug with setting breakpoints on C++11 inline initialization statements.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2021-01-20T17:58:34-08:00
New Revision: bff389120fa2368d123612449c938958cfd7f45e

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

LOG: Fix a bug with setting breakpoints on C++11 inline initialization 
statements.

If they occurred before the constructor that used them, we would refuse to
set the breakpoint because we thought they were crossing function boundaries.

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

Added: 
lldb/test/API/lang/cpp/break-on-initializers/Makefile
lldb/test/API/lang/cpp/break-on-initializers/TestBreakOnCPP11Initializers.py
lldb/test/API/lang/cpp/break-on-initializers/main.cpp

Modified: 
lldb/source/Breakpoint/BreakpointResolverFileLine.cpp

Removed: 




diff  --git a/lldb/source/Breakpoint/BreakpointResolverFileLine.cpp 
b/lldb/source/Breakpoint/BreakpointResolverFileLine.cpp
index 22a4b4ae33ae..5ca4ef5834e0 100644
--- a/lldb/source/Breakpoint/BreakpointResolverFileLine.cpp
+++ b/lldb/source/Breakpoint/BreakpointResolverFileLine.cpp
@@ -187,6 +187,14 @@ void 
BreakpointResolverFileLine::FilterContexts(SymbolContextList &sc_list,
 // is 0, then we can't do this calculation.  That can happen if
 // GetStartLineSourceInfo gets an error, or if the first line number in
 // the function really is 0 - which happens for some languages.
+
+// But only do this calculation if the line number we found in the SC
+// was 
diff erent from the one requested in the source file.  If we actually
+// found an exact match it must be valid.
+
+if (m_line_number == sc.line_entry.line)
+  continue;
+
 const int decl_line_is_too_late_fudge = 1;
 if (line && m_line_number < line - decl_line_is_too_late_fudge) {
   LLDB_LOG(log, "removing symbol context at {0}:{1}", file, line);

diff  --git a/lldb/test/API/lang/cpp/break-on-initializers/Makefile 
b/lldb/test/API/lang/cpp/break-on-initializers/Makefile
new file mode 100644
index ..7714f26e52bc
--- /dev/null
+++ b/lldb/test/API/lang/cpp/break-on-initializers/Makefile
@@ -0,0 +1,4 @@
+C_SOURCES := main.c
+CXXFLAGS_EXTRAS := -std=c++11
+
+include Makefile.rules

diff  --git 
a/lldb/test/API/lang/cpp/break-on-initializers/TestBreakOnCPP11Initializers.py 
b/lldb/test/API/lang/cpp/break-on-initializers/TestBreakOnCPP11Initializers.py
new file mode 100644
index ..8456a7cae96e
--- /dev/null
+++ 
b/lldb/test/API/lang/cpp/break-on-initializers/TestBreakOnCPP11Initializers.py
@@ -0,0 +1,52 @@
+"""
+When using C++11 in place member initialization, show that we
+can set and hit breakpoints on initialization lines.  This is a
+little bit tricky because we try not to move file and line breakpoints 
+across function boundaries but these lines are outside the source range
+of the constructor.
+"""
+
+
+
+import lldb
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+
+class RenameThisSampleTestTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_breakpoints_on_initializers(self):
+"""Show we can set breakpoints on initializers appearing both before
+   and after the constructor body, and hit them."""
+self.build()
+self.main_source_file = lldb.SBFileSpec("main.cpp")
+self.first_initializer_line = line_number("main.cpp", "Set the before 
constructor breakpoint here")
+self.second_initializer_line = line_number("main.cpp", "Set the after 
constructor breakpoint here")
+self.sample_test()
+
+def setUp(self):
+# Call super's setUp().
+TestBase.setUp(self)
+# Set up your test case here. If your test doesn't need any set up then
+# remove this method from your TestCase class.
+
+def sample_test(self):
+"""You might use the test implementation in several ways, say so 
here."""
+
+(target, process, thread, bkpt) = 
lldbutil.run_to_source_breakpoint(self,
+   " Set a breakpoint here to get started", 
self.main_source_file)
+
+# Now set breakpoints on the two initializer lines we found in the 
test startup:
+bkpt1 = target.BreakpointCreateByLocation(self.main_source_file, 
self.first_initializer_line)
+self.assertEqual(bkpt1.GetNumLocations(), 1)
+bkpt2 = target.BreakpointCreateByLocation(self.main_source_file, 
self.second_initializer_line)
+self.assertEqual(bkpt2.GetNumLocations(), 1)
+
+# Now continue, we should stop at the two breakpoints above, first the 
one before, then
+# the one after.
+self.assertEqual(len(lldbutil.continue_to_breakpoint(process, bkpt1)), 
1, "Hit first breakpoint")
+self.assertEqual(len(lldbutil.continue_to_breakpoint(process, bkpt2

Re: [Lldb-commits] [PATCH] D94846: Allow breakpoints to be set on C++11 inline initializers

[Jim Ingham via lldb-commits]

> On Jan 19, 2021, at 3:34 PM, David Blaikie  wrote:
> 
> On Tue, Jan 19, 2021 at 2:55 PM Jim Ingham  wrote:
>> 
>> 
>> 
>>> On Jan 19, 2021, at 11:40 AM, David Blaikie  wrote:
>>> 
>>> On Tue, Jan 19, 2021 at 10:17 AM Jim Ingham  wrote:
 
 
 
> On Jan 17, 2021, at 10:47 AM, David Blaikie  wrote:
> 
> On Fri, Jan 15, 2021 at 6:22 PM Jim Ingham  wrote:
>> 
>> If you set a breakpoint on source lines with no line table entries, lldb 
>> slides the actual match forward to the nearest line table entry to the 
>> given line number.  That's necessary for instance because if you lay out 
>> your function definitions over multiple lines they won't all get line 
>> table entries, but we don't want people to have to guess which of them 
>> was...  Same is true of more complicated compound statements.
> 
> Ah, sure - gdb seems to do that too, totally makes sense - as you say,
> it'd be pretty hard to know exactly which tokens end up with
> corresponding entries in the line table and which don't (especially
> under optimizations and complex compound statements).
 
 Yeah, I think you either have to have this heuristic, or have a debugger 
 that can display "valid breakpoint locations".  The old Metrowerks 
 debugger used to do it that way.  They only put up breakpoint affordances 
 in the UI for the lines that had line table entries and there was no 
 free-form way to set breakpoints, so you couldn't do an ambiguous thing.  
 But I don't think we have that option in lldb.
>>> 
>>> Could be nice to have in source printing on the command line and could
>>> be done more fully in IDE integrations like XCode - but yeah, still
>>> would want all this sliding stuff for raw command line usage even if
>>> we had the rest.
>> 
>> If we just cared about lines and not columns, it would be pretty easy to 
>> annotate the source line output, maybe just a • before each breakable line.  
>> Marking the column locations as well, while keeping the whole thing 
>> readable, is a bit trickier.
>> 
>> The problem with Xcode is that they don't do full compiles as you are 
>> editing.  They do run the front end for code completion, brace matching, 
>> etc...  But that doesn't generate line tables.  So you would have to support 
>> breakpoints in files where you do and don't know the valid line table 
>> entries.  If you didn't design for using the compiled code for UI in the 
>> IDE, it's not easy to add it in after the fact.
>> 
>>> 
>> So people like that, but they really hate it when they have:
>> 
>> 
>> #ifdef SOMETHING_NOT_DEFINED
>> 
>> int foo() {
>> 
>> }
>> 
>> #else
>> int bar() {
>> 
>> }
>> #end
>> 
>> but with lots more junk so you can't see the ifdef's and then they set a 
>> breakpoint in the "int foo" part and the breakpoint gets moved to bar 
>> instead and then doesn't get hit.
> 
> Ah, indeed - that is a curious case that could be surprising to a
> user. Thanks for explaining it - though it seems gdb doesn't special
> case this & does produce the not-quite-what-the-user-intended
> behavior.
> 
>> You might try to argue that they should have checked where the 
>> breakpoint actually landed before coming into your office to yell at 
>> you, but it's likely to leave you with fewer friends...
> 
> FWIW: I don't have coworkers or friends come into my office to yell at
> me about anything like this, and I don't really think anyone should -
> that's not appropriate behavior for a workplace.
> 
> Having a nuanced discussion about the tradeoff of features - sure.
 
 Yeah, IME people get cheesed off at debuggers in ways they don't with 
 compilers.  I have some theories, but more of the after work quality than 
 the public mailing list quality.
 
>> So I was trying to detect this case and not move the breakpoint if 
>> sliding it crossed over the function start boundary.  That way you'd see 
>> that the breakpoint didn't work, and go figure out why.
> 
> Neat idea!
> 
>> The thinko in the original version was that we were still doing this 
>> when we DIDN'T have to slide the breakpoint, when we got an exact match 
>> in the line table.  In that case, we shouldn't try to second guess the 
>> line table at all.  That's the patch in this fix.
> 
> Might this still leave some confusing behavior. Now it'll slide
> forward into a function, but it won't slide forward into an
> initializer? (so now the user has to know exactly which lines of the
> initializer are attributed to the line table, making that somewhat
> difficult to use?)
 
 
 Yes I knew this was a tradeoff of the implementation.  If I did a more in 
 depth search in order to slide this over to function initializer, it would 
 IMO add way more com

Re: [Lldb-commits] [PATCH] D94846: Allow breakpoints to be set on C++11 inline initializers

[Jim Ingham via lldb-commits]

> On Jan 19, 2021, at 11:40 AM, David Blaikie  wrote:
> 
> On Tue, Jan 19, 2021 at 10:17 AM Jim Ingham  wrote:
>> 
>> 
>> 
>>> On Jan 17, 2021, at 10:47 AM, David Blaikie  wrote:
>>> 
>>> On Fri, Jan 15, 2021 at 6:22 PM Jim Ingham  wrote:
 
 If you set a breakpoint on source lines with no line table entries, lldb 
 slides the actual match forward to the nearest line table entry to the 
 given line number.  That's necessary for instance because if you lay out 
 your function definitions over multiple lines they won't all get line 
 table entries, but we don't want people to have to guess which of them 
 was...  Same is true of more complicated compound statements.
>>> 
>>> Ah, sure - gdb seems to do that too, totally makes sense - as you say,
>>> it'd be pretty hard to know exactly which tokens end up with
>>> corresponding entries in the line table and which don't (especially
>>> under optimizations and complex compound statements).
>> 
>> Yeah, I think you either have to have this heuristic, or have a debugger 
>> that can display "valid breakpoint locations".  The old Metrowerks debugger 
>> used to do it that way.  They only put up breakpoint affordances in the UI 
>> for the lines that had line table entries and there was no free-form way to 
>> set breakpoints, so you couldn't do an ambiguous thing.  But I don't think 
>> we have that option in lldb.
> 
> Could be nice to have in source printing on the command line and could
> be done more fully in IDE integrations like XCode - but yeah, still
> would want all this sliding stuff for raw command line usage even if
> we had the rest.

If we just cared about lines and not columns, it would be pretty easy to 
annotate the source line output, maybe just a • before each breakable line.  
Marking the column locations as well, while keeping the whole thing readable, 
is a bit trickier.

The problem with Xcode is that they don't do full compiles as you are editing.  
They do run the front end for code completion, brace matching, etc...  But that 
doesn't generate line tables.  So you would have to support breakpoints in 
files where you do and don't know the valid line table entries.  If you didn't 
design for using the compiled code for UI in the IDE, it's not easy to add it 
in after the fact.

> 
 So people like that, but they really hate it when they have:
 
 
 #ifdef SOMETHING_NOT_DEFINED
 
 int foo() {
 
 }
 
 #else
 int bar() {
 
 }
 #end
 
 but with lots more junk so you can't see the ifdef's and then they set a 
 breakpoint in the "int foo" part and the breakpoint gets moved to bar 
 instead and then doesn't get hit.
>>> 
>>> Ah, indeed - that is a curious case that could be surprising to a
>>> user. Thanks for explaining it - though it seems gdb doesn't special
>>> case this & does produce the not-quite-what-the-user-intended
>>> behavior.
>>> 
 You might try to argue that they should have checked where the breakpoint 
 actually landed before coming into your office to yell at you, but it's 
 likely to leave you with fewer friends...
>>> 
>>> FWIW: I don't have coworkers or friends come into my office to yell at
>>> me about anything like this, and I don't really think anyone should -
>>> that's not appropriate behavior for a workplace.
>>> 
>>> Having a nuanced discussion about the tradeoff of features - sure.
>> 
>> Yeah, IME people get cheesed off at debuggers in ways they don't with 
>> compilers.  I have some theories, but more of the after work quality than 
>> the public mailing list quality.
>> 
 So I was trying to detect this case and not move the breakpoint if sliding 
 it crossed over the function start boundary.  That way you'd see that the 
 breakpoint didn't work, and go figure out why.
>>> 
>>> Neat idea!
>>> 
 The thinko in the original version was that we were still doing this when 
 we DIDN'T have to slide the breakpoint, when we got an exact match in the 
 line table.  In that case, we shouldn't try to second guess the line table 
 at all.  That's the patch in this fix.
>>> 
>>> Might this still leave some confusing behavior. Now it'll slide
>>> forward into a function, but it won't slide forward into an
>>> initializer? (so now the user has to know exactly which lines of the
>>> initializer are attributed to the line table, making that somewhat
>>> difficult to use?)
>> 
>> 
>> Yes I knew this was a tradeoff of the implementation.  If I did a more in 
>> depth search in order to slide this over to function initializer, it would 
>> IMO add way more complexity to an already overly fiddly part of the 
>> debugger, and the trade-off didn't seem worth it.  Most initializers have a 
>> fairly simple structure, as opposed say to the before the body part of a 
>> function definition (that's got to have a name, but I don't know it off the 
>> top of my head.)  So I think the payoff would be a lot le

Re: [Lldb-commits] [PATCH] D94846: Allow breakpoints to be set on C++11 inline initializers

[Jim Ingham via lldb-commits]

> On Jan 17, 2021, at 10:47 AM, David Blaikie  wrote:
> 
> On Fri, Jan 15, 2021 at 6:22 PM Jim Ingham  wrote:
>> 
>> If you set a breakpoint on source lines with no line table entries, lldb 
>> slides the actual match forward to the nearest line table entry to the given 
>> line number.  That's necessary for instance because if you lay out your 
>> function definitions over multiple lines they won't all get line table 
>> entries, but we don't want people to have to guess which of them was...  
>> Same is true of more complicated compound statements.
> 
> Ah, sure - gdb seems to do that too, totally makes sense - as you say,
> it'd be pretty hard to know exactly which tokens end up with
> corresponding entries in the line table and which don't (especially
> under optimizations and complex compound statements).

Yeah, I think you either have to have this heuristic, or have a debugger that 
can display "valid breakpoint locations".  The old Metrowerks debugger used to 
do it that way.  They only put up breakpoint affordances in the UI for the 
lines that had line table entries and there was no free-form way to set 
breakpoints, so you couldn't do an ambiguous thing.  But I don't think we have 
that option in lldb.

> 
>> So people like that, but they really hate it when they have:
>> 
>> 
>> #ifdef SOMETHING_NOT_DEFINED
>> 
>> int foo() {
>> 
>> }
>> 
>> #else
>> int bar() {
>> 
>> }
>> #end
>> 
>> but with lots more junk so you can't see the ifdef's and then they set a 
>> breakpoint in the "int foo" part and the breakpoint gets moved to bar 
>> instead and then doesn't get hit.
> 
> Ah, indeed - that is a curious case that could be surprising to a
> user. Thanks for explaining it - though it seems gdb doesn't special
> case this & does produce the not-quite-what-the-user-intended
> behavior.
> 
>> You might try to argue that they should have checked where the breakpoint 
>> actually landed before coming into your office to yell at you, but it's 
>> likely to leave you with fewer friends...
> 
> FWIW: I don't have coworkers or friends come into my office to yell at
> me about anything like this, and I don't really think anyone should -
> that's not appropriate behavior for a workplace.
> 
> Having a nuanced discussion about the tradeoff of features - sure.

Yeah, IME people get cheesed off at debuggers in ways they don't with 
compilers.  I have some theories, but more of the after work quality than the 
public mailing list quality.

> 
>> So I was trying to detect this case and not move the breakpoint if sliding 
>> it crossed over the function start boundary.  That way you'd see that the 
>> breakpoint didn't work, and go figure out why.
> 
> Neat idea!
> 
>> The thinko in the original version was that we were still doing this when we 
>> DIDN'T have to slide the breakpoint, when we got an exact match in the line 
>> table.  In that case, we shouldn't try to second guess the line table at 
>> all.  That's the patch in this fix.
> 
> Might this still leave some confusing behavior. Now it'll slide
> forward into a function, but it won't slide forward into an
> initializer? (so now the user has to know exactly which lines of the
> initializer are attributed to the line table, making that somewhat
> difficult to use?)


Yes I knew this was a tradeoff of the implementation.  If I did a more in depth 
search in order to slide this over to function initializer, it would IMO add 
way more complexity to an already overly fiddly part of the debugger, and the 
trade-off didn't seem worth it.  Most initializers have a fairly simple 
structure, as opposed say to the before the body part of a function definition 
(that's got to have a name, but I don't know it off the top of my head.)  So I 
think the payoff would be a lot less in this area.  I asked around here and the 
folks I polled agreed that it wasn't worth the complexity.

> 
> Testing some things out:
> 
> $ cat break.cpp
> __attribute__((optnone)) int f1() { return 1; }
> struct t1 {
>  int // 3
>  i   // 4
>  =   // 5
>  f1  // 6
>  ();
>  t1() {
>  }
> };
> 
> t1 v1;
> int main() {
> }
> 
> The line table:
> 
> AddressLine   Column File   ISA Discriminator Flags
> -- -- -- -- --- - -
> 0x00401140  1  0  1   0 0  is_stmt
> 0x00401144  1 37  1   0 0  is_stmt 
> prologue_end
> 0x00401150 13  0  1   0 0  is_stmt
> 0x00401154 14  1  1   0 0  is_stmt 
> prologue_end
> 0x00401158 14  1  1   0 0  is_stmt 
> end_sequence
> 0x00401020  0  0  1   0 0  is_stmt
> 0x00401024 12  4  1   0 0  is_stmt 
> prologue_end
> 0x00401040  0  0  1   0 0  is_stmt
> 0x0040104b  0  0  1   0 0  is_stmt 
> end_sequence
> 

Re: [Lldb-commits] [PATCH] D94846: Allow breakpoints to be set on C++11 inline initializers

[Jim Ingham via lldb-commits]

If you set a breakpoint on source lines with no line table entries, lldb slides 
the actual match forward to the nearest line table entry to the given line 
number.  That's necessary for instance because if you lay out your function 
definitions over multiple lines they won't all get line table entries, but we 
don't want people to have to guess which of them was...  Same is true of more 
complicated compound statements.

So people like that, but they really hate it when they have:


#ifdef SOMETHING_NOT_DEFINED

int foo() {

}

#else
int bar() {

}
#end

but with lots more junk so you can't see the ifdef's and then they set a 
breakpoint in the "int foo" part and the breakpoint gets moved to bar instead 
and then doesn't get hit.  You might try to argue that they should have checked 
where the breakpoint actually landed before coming into your office to yell at 
you, but it's likely to leave you with fewer friends...

So I was trying to detect this case and not move the breakpoint if sliding it 
crossed over the function start boundary.  That way you'd see that the 
breakpoint didn't work, and go figure out why.

The thinko in the original version was that we were still doing this when we 
DIDN'T have to slide the breakpoint, when we got an exact match in the line 
table.  In that case, we shouldn't try to second guess the line table at all.  
That's the patch in this fix.

BTW, the check wouldn't have affected code from .defs files because I only do 
it if the original breakpoint specification and the "function start" are from 
the same source file.  And we know about inlined blocks so inlining isn't going 
to fool us either.

Jim




> On Jan 15, 2021, at 5:09 PM, David Blaikie  wrote:
> 
> "But because their source lines are outside the function source range"
> 
> Not sure I understand that - the DWARF doesn't describe a function
> source range, right? Only the line a function starts on. And a
> function can have code from source lines in many files/offsets that
> are unrelated to the function start line (LLVM in several places
> #includes .def files into functions to stamp out tables, switches,
> arrays, etc, for instance)
> 
> On Fri, Jan 15, 2021 at 4:47 PM Jim Ingham via Phabricator via
> lldb-commits  wrote:
>> 
>> jingham created this revision.
>> jingham requested review of this revision.
>> Herald added a project: LLDB.
>> Herald added a subscriber: lldb-commits.
>> 
>> The inline initializers contribute code to the constructor(s).  You will 
>> step onto them in the source view as you step through the constructor, for 
>> instance.  But because their source lines are outside the function source 
>> range, lldb thought a breakpoint on the initializer line was crossing from 
>> one function to another, which file & line breakpoints don't allow.  That 
>> meant if you tried to set a breakpoint on one of these lines it doesn't 
>> create any locations.
>> 
>> This patch fixes that by asserting that if the LineEntry in one of the 
>> SymbolContexts that the search produced exactly matches the file & line 
>> specifications in the breakpoint, it has to be a valid place to set the 
>> breakpoint, and we should just set it.
>> 
>> 
>> Repository:
>>  rG LLVM Github Monorepo
>> 
>> https://reviews.llvm.org/D94846
>> 
>> Files:
>>  lldb/source/Breakpoint/BreakpointResolverFileLine.cpp
>>  lldb/test/API/lang/cpp/break-on-initializers/Makefile
>>  lldb/test/API/lang/cpp/break-on-initializers/TestBreakOnCPP11Initializers.py
>>  lldb/test/API/lang/cpp/break-on-initializers/main.cpp
>> 
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

[Jim Ingham via lldb-commits]

oogle/home/blaikie/dev/llvm/build/default/bin/clang-x86_64)
> :: test_and_python_api (TestStepAndBreakpoints.TestCStepping)
> ==
> FAIL: test_and_python_api (TestStepAndBreakpoints.TestCStepping)
>   Test stepping over vrs. hitting breakpoints & subsequent stepping
> in various forms.
> --
> Traceback (most recent call last):
>  File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/decorators.py",
> line 345, in wrapper
>return func(self, *args, **kwargs)
>  File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/decorators.py",
> line 135, in wrapper
>return func(*args, **kwargs)
>  File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/decorators.py",
> line 135, in wrapper
>return func(*args, **kwargs)
>  File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/decorators.py",
> line 105, in wrapper
>func(*args, **kwargs)
>  File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/decorators.py",
> line 105, in wrapper
>func(*args, **kwargs)
>  File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/decorators.py",
> line 105, in wrapper
>func(*args, **kwargs)
>  [Previous line repeated 1 more time]
>  File 
> "/usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/lang/c/stepping/TestStepAndBreakpoints.py",
> line 48, in test_and_python_api
>
> self.assertEqual(get_description(break_1_in_main.locations[0].GetAddress().line_entry),
> "narf")
> AssertionError:
> '/usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/lang/c/stepping/main.c:40:14'
> != 'narf'
> - 
> /usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/lang/c/stepping/main.c:40:14+
> narf
> Config=x86_64-/usr/local/google/home/blaikie/dev/llvm/build/default/bin/clang
> --
> Ran 1 test in 0.320s
> 
> RESULT: FAILED (0 passes, 1 failures, 0 errors, 0 skipped, 0 expected
> failures, 0 unexpected successes)
> 
> --
> 
> 
> 
> Failed Tests (1):
>  lldb-api :: lang/c/stepping/TestStepAndBreakpoints.py
> 
> 
> Testing Time: 0.77s
>  Failed: 1
> 
> $ 
> LD_LIBRARY_PATH=/usr/local/google/home/blaikie/dev/llvm/build/default/lib:/usr/local/google/home/blaikie/install/lib:/usr/local/google/home/blaikie/install/lib64
> ./bin/lldb 
> ./lldb-test-build.noindex/lang/c/stepping/TestStepAndBreakpoints.test_and_python_api/a.out
> (lldb) target create
> "./lldb-test-build.noindex/lang/c/stepping/TestStepAndBreakpoints.test_and_python_api/a.out"
> Current executable set to
> '/usr/local/google/home/blaikie/dev/llvm/build/default/lldb-test-build.noindex/lang/c/stepping/TestStepAndBreakpoints.test_and_python_api/a.out'
> (x86_64).
> (lldb) b main.c:40
> Breakpoint 1: where = a.out`main + 22, address = 0x004011c6
> (lldb) b main
> Breakpoint 2: where = a.out`main + 22, address = 0x004011c6
> (lldb) b a
> Breakpoint 3: where = a.out`a + 11 at main.c:8:24, address = 
> 0x0040111b
> (lldb)
> 
> 
> 
> On Mon, Jan 11, 2021 at 11:13 AM Jim Ingham  wrote:
>> 
>> 
>> 
>>> On Jan 10, 2021, at 5:37 PM, David Blaikie  wrote:
>>> 
>>> Thanks for all the context - so sounds like mostly based on (3) the 
>>> recommendation would be for this to be an API test (is there a way to test 
>>> the line table directly? good place for reference on the SB API options - I 
>>> looked at a few tests and they seemed quite different ( 
>>> lldb/test/API/functionalities/breakpoint/move_nearest/TestMoveNearest.py 
>>> and 
>>> lldb/test/API/commands/breakpoint/set/func-regex/TestBreakpointRegexError.py
>>>  ) in the way they're written, so not sure what the norms are/how they 
>>> work).
>>> 
>> 
>> You can get directly at the line table from the SB API's.  There's an 
>> example of doing just that on the SBCompileUnit page:
>> 
>> https://lldb.llvm.org/python_reference/lldb.SBCompileUnit-class.html
>> 
>> There's a small sample test in API/sample_test which is a good place to 
>> start.  That one assumes you are running the target, however, which you may 
>> or may not need to do.  We've accumulated lots of conve

Re: [Lldb-commits] [PATCH] D93874: [process] fix exec support on Linux

[Jim Ingham via lldb-commits]

Thanks for looking into this further!  The thing to figure out is who still has 
a reference to either the Thread * or to the ThreadPlanStack over the 
destruction of the thread.  That shouldn't be allowed to happen.

Jim

> On Jan 11, 2021, at 10:01 PM, walter erquinigo via Phabricator 
>  wrote:
> 
> wallace added a comment.
> 
> I've done a lightweight test and it seems that the BaseThreadPlan is being 
> asked for the stop reason when the exec happens, but it holds a reference to 
> the thread whose destructor has been called, which causes the crash. On 
> Darwin, as Greg said, the BaseThreadPlan is deleted when the thread changes, 
> so this doesn't happen.
> Later this week I'll spend more time gathering logs and I'll share them here 
> in a nice format.
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D93874/new/
> 
> https://reviews.llvm.org/D93874
> 

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

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

[Jim Ingham via lldb-commits]

> On Jan 10, 2021, at 5:37 PM, David Blaikie  wrote:
> 
> Thanks for all the context - so sounds like mostly based on (3) the 
> recommendation would be for this to be an API test (is there a way to test 
> the line table directly? good place for reference on the SB API options - I 
> looked at a few tests and they seemed quite different ( 
> lldb/test/API/functionalities/breakpoint/move_nearest/TestMoveNearest.py and 
> lldb/test/API/commands/breakpoint/set/func-regex/TestBreakpointRegexError.py 
> ) in the way they're written, so not sure what the norms are/how they work).
> 

You can get directly at the line table from the SB API's.  There's an example 
of doing just that on the SBCompileUnit page:

https://lldb.llvm.org/python_reference/lldb.SBCompileUnit-class.html

There's a small sample test in API/sample_test which is a good place to start.  
That one assumes you are running the target, however, which you may or may not 
need to do.  We've accumulated lots of convenience methods over time to make 
testing easier, but we haven't back ported them to old tests.  If you want 
other models than the sample_test, look for ones made more recently.

There's some description of the API tests here:

https://lldb.llvm.org/resources/test.html

and some test writing info in the sources in:

llvm-project/lldb/docs/testsuite/best-practices.txt


> But more fundamentally, seems all the API tests are "unsupported" on my 
> system, and I can't seem to figure out what makes them unsupported according 
> to lit. Any ideas?

I don't know much about how the lit runner works, somebody else will have to 
answer that.

Jim

> 
> On Thu, Jan 7, 2021 at 4:55 PM Jim Ingham  wrote:
> 
> 
> > On Jan 7, 2021, at 3:57 PM, David Blaikie  wrote:
> > 
> > On Thu, Jan 7, 2021 at 3:37 PM Jim Ingham via lldb-commits
> >  wrote:
> >> 
> >> 
> >> 
> >>> On Jan 7, 2021, at 2:29 PM, David Blaikie via Phabricator via 
> >>> lldb-commits  wrote:
> >>> 
> >>> dblaikie added a comment.
> >>> 
> >>> In D94063#2485271 <https://reviews.llvm.org/D94063#2485271>, @labath 
> >>> wrote:
> >>> 
> >>>> In D94063#2483546 <https://reviews.llvm.org/D94063#2483546>, @dblaikie 
> >>>> wrote:
> >>>> 
> >>>>> If it's better to write it using C++ source and custom clang flags I 
> >>>>> can do that instead (it'll be an -mllvm flag - looks like there's one 
> >>>>> other test that does that: 
> >>>>> `lldb/test/API/lang/objc/forward-decl/TestForwardDecl.py:
> >>>>> dict(CFLAGS_EXTRAS="-dwarf-version=5 -mllvm -accel-tables=Dwarf"))`) - 
> >>>>> means the test will be a bit more convoluted to tickle the subprogram 
> >>>>> ranges, but not much - just takes two functions+function-sections.
> >>>> 
> >>>> I certainly wouldn't want to drop the existing test.
> >>> 
> >>> Ah, what's the tradeoff between the different test types here?
> >> 
> >> This is my take (this has been a contentious issue so I'm sure there are 
> >> other takes...):
> >> 
> >> The "Shell" tests use pattern matching against the lldb command line 
> >> output.  They are useful for testing the details of the command 
> >> interaction. You can also do that using pexpect in the API tests, but the 
> >> Python 2.7 version of pexpect seemed really flakey so we switched to shell 
> >> tests for this sort of thing.
> >> 
> >> Because you are matching against text output that isn't API, they are less 
> >> stable.  For instance if we changed anything in the "break set" output, 
> >> your test would fail(*).  And because you are picking details out of that 
> >> text, the tests are less precise.  You either have to match more of the 
> >> command line than you are actually testing for, which isn't a good 
> >> practice, or you run the risk of finding the text you were looking for in 
> >> a directory path or other unrelated part of the output.  Also they are 
> >> harder to debug if you can't reproduce the failure locally, since it isn't 
> >> easy to add internal checks/output to the test to try hypotheses.  
> >> Whenever I have run into failures of this sort the first thing I do is 
> >> convert the test to an API test...
> >> 
> >> But the main benefit of the "Shell" tests is that you can write tests 
> >&g

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

[Jim Ingham via lldb-commits]

> On Jan 7, 2021, at 3:57 PM, David Blaikie  wrote:
> 
> On Thu, Jan 7, 2021 at 3:37 PM Jim Ingham via lldb-commits
>  wrote:
>> 
>> 
>> 
>>> On Jan 7, 2021, at 2:29 PM, David Blaikie via Phabricator via lldb-commits 
>>>  wrote:
>>> 
>>> dblaikie added a comment.
>>> 
>>> In D94063#2485271 <https://reviews.llvm.org/D94063#2485271>, @labath wrote:
>>> 
>>>> In D94063#2483546 <https://reviews.llvm.org/D94063#2483546>, @dblaikie 
>>>> wrote:
>>>> 
>>>>> If it's better to write it using C++ source and custom clang flags I can 
>>>>> do that instead (it'll be an -mllvm flag - looks like there's one other 
>>>>> test that does that: 
>>>>> `lldb/test/API/lang/objc/forward-decl/TestForwardDecl.py:
>>>>> dict(CFLAGS_EXTRAS="-dwarf-version=5 -mllvm -accel-tables=Dwarf"))`) - 
>>>>> means the test will be a bit more convoluted to tickle the subprogram 
>>>>> ranges, but not much - just takes two functions+function-sections.
>>>> 
>>>> I certainly wouldn't want to drop the existing test.
>>> 
>>> Ah, what's the tradeoff between the different test types here?
>> 
>> This is my take (this has been a contentious issue so I'm sure there are 
>> other takes...):
>> 
>> The "Shell" tests use pattern matching against the lldb command line output. 
>>  They are useful for testing the details of the command interaction. You can 
>> also do that using pexpect in the API tests, but the Python 2.7 version of 
>> pexpect seemed really flakey so we switched to shell tests for this sort of 
>> thing.
>> 
>> Because you are matching against text output that isn't API, they are less 
>> stable.  For instance if we changed anything in the "break set" output, your 
>> test would fail(*).  And because you are picking details out of that text, 
>> the tests are less precise.  You either have to match more of the command 
>> line than you are actually testing for, which isn't a good practice, or you 
>> run the risk of finding the text you were looking for in a directory path or 
>> other unrelated part of the output.  Also they are harder to debug if you 
>> can't reproduce the failure locally, since it isn't easy to add internal 
>> checks/output to the test to try hypotheses.  Whenever I have run into 
>> failures of this sort the first thing I do is convert the test to an API 
>> test...
>> 
>> But the main benefit of the "Shell" tests is that you can write tests 
>> without having to know Python or learn the lldb Python API's.  And if you 
>> are coming from clang you already know how FileCheck tests work, so that's a 
>> bonus.  I think it's legit to require that folks actually working on lldb 
>> learn the SB API's.  But we were persuaded that it wasn't fair to impose 
>> that on people not working on lldb, and yet such folks do sometimes need to 
>> write tests for lldb...  So for simple tests, the Shell tests are an okay 
>> option.  But really, there's nothing you can do in a Shell test that you 
>> can't do in an API test.
>> 
>> The "API" tests use the Python SB API's - though they also have the ability 
>> to run commands and do expect type checks on the output so for single 
>> commands they work much as the shell tests do (there's even a FileCheck 
>> style assert IIRC).  They are a little more verbose than shell tests (though 
>> we've reduced the boilerplate significantly over the years).  And of course 
>> you have to know the SB API's.  But for instance, if you wanted to know that 
>> a breakpoint was set on line 5 of foo.c, you can set the breakpoint, then 
>> ask the resultant SBBreakpoint object what it's file & line numbers were 
>> directly.  So once you've gotten familiar with the setup, IMO you can write 
>> much higher quality tests with the API tests.
>> 
>> 
>> Jim
>> 
>> (*) I am personally not at all in favor of the Shell tests, but that's in 
>> part because back in the day I was asked to make a simple and useful change 
>> to the output of the gdb "break" command but then righting the gdb testsuite 
>> - which is all based on expecting the results of various gdb commands - was 
>> so tedious that we ended up dropping the change instead.  I don't want to 
>> get to that place with lldb, but the hope is that as long as

Re: [Lldb-commits] [PATCH] D94063: lldb: Add support for DW_AT_ranges on DW_TAG_subprograms

[Jim Ingham via lldb-commits]

> On Jan 7, 2021, at 2:29 PM, David Blaikie via Phabricator via lldb-commits 
>  wrote:
> 
> dblaikie added a comment.
> 
> In D94063#2485271 , @labath wrote:
> 
>> In D94063#2483546 , @dblaikie wrote:
>> 
>>> If it's better to write it using C++ source and custom clang flags I can do 
>>> that instead (it'll be an -mllvm flag - looks like there's one other test 
>>> that does that: `lldb/test/API/lang/objc/forward-decl/TestForwardDecl.py:   
>>>  dict(CFLAGS_EXTRAS="-dwarf-version=5 -mllvm 
>>> -accel-tables=Dwarf"))`) - means the test will be a bit more convoluted to 
>>> tickle the subprogram ranges, but not much - just takes two 
>>> functions+function-sections.
>> 
>> I certainly wouldn't want to drop the existing test.
> 
> Ah, what's the tradeoff between the different test types here?

This is my take (this has been a contentious issue so I'm sure there are other 
takes...):

The "Shell" tests use pattern matching against the lldb command line output.  
They are useful for testing the details of the command interaction.  You can 
also do that using pexpect in the API tests, but the Python 2.7 version of 
pexpect seemed really flakey so we switched to shell tests for this sort of 
thing.

Because you are matching against text output that isn't API, they are less 
stable.  For instance if we changed anything in the "break set" output, your 
test would fail(*).  And because you are picking details out of that text, the 
tests are less precise.  You either have to match more of the command line than 
you are actually testing for, which isn't a good practice, or you run the risk 
of finding the text you were looking for in a directory path or other unrelated 
part of the output.  Also they are harder to debug if you can't reproduce the 
failure locally, since it isn't easy to add internal checks/output to the test 
to try hypotheses.  Whenever I have run into failures of this sort the first 
thing I do is convert the test to an API test...

But the main benefit of the "Shell" tests is that you can write tests without 
having to know Python or learn the lldb Python API's.  And if you are coming 
from clang you already know how FileCheck tests work, so that's a bonus.  I 
think it's legit to require that folks actually working on lldb learn the SB 
API's.  But we were persuaded that it wasn't fair to impose that on people not 
working on lldb, and yet such folks do sometimes need to write tests for 
lldb...  So for simple tests, the Shell tests are an okay option.  But really, 
there's nothing you can do in a Shell test that you can't do in an API test.

The "API" tests use the Python SB API's - though they also have the ability to 
run commands and do expect type checks on the output so for single commands 
they work much as the shell tests do (there's even a FileCheck style assert 
IIRC).  They are a little more verbose than shell tests (though we've reduced 
the boilerplate significantly over the years).  And of course you have to know 
the SB API's.  But for instance, if you wanted to know that a breakpoint was 
set on line 5 of foo.c, you can set the breakpoint, then ask the resultant 
SBBreakpoint object what it's file & line numbers were directly.  So once 
you've gotten familiar with the setup, IMO you can write much higher quality 
tests with the API tests.


Jim

(*) I am personally not at all in favor of the Shell tests, but that's in part 
because back in the day I was asked to make a simple and useful change to the 
output of the gdb "break" command but then righting the gdb testsuite - which 
is all based on expecting the results of various gdb commands - was so tedious 
that we ended up dropping the change instead.  I don't want to get to that 
place with lldb, but the hope is that as long as we mostly write API tests, we 
can avoid encumbering the current command outputs too heavily...

Jim

> 
>> However, it could be useful to have c++ test too. This one could feature a 
>> more complicated executable, and be more open-ended/exploratory and test 
>> end-to-end functionality (including compiler integration), instead of a 
>> targeted "did we parse DW_AT_ranges correctly" regression test. Then this 
>> test could go into the `API` test category, as we have the ability to run 
>> those kinds of tests against different compilers.
> 
> Does this include support for custom compiler flags (it'd currently take a 
> non-official/internal-only llvm flag to create the DW_AT_ranges on a 
> subprogram that I have in mind, for instance)?
> 
>> However, all of that is strictly optional.
> 
> I'll consider it for a separate commit.
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D94063/new/
> 
> https://reviews.llvm.org/D94063
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.o

Re: [Lldb-commits] [PATCH] D91734: [FastISel] Flush local value map on every instruction

[Jim Ingham via lldb-commits]

> On Dec 3, 2020, at 5:43 PM, Robinson, Paul  wrote:
> 
> 
> 
>> -Original Message-
>> From: Jim Ingham mailto:jing...@apple.com>>
>> Sent: Thursday, December 3, 2020 5:51 PM
>> To: David Blaikie
>> > >; David 
>> Blaikie
>> via Phabricator mailto:revi...@reviews.llvm.org>>
>> Cc: Robinson, Paul mailto:paul.robin...@sony.com>>; 
>> r...@google.com ;
>> echri...@gmail.com ; sontuan.vu...@gmail.com 
>> ; mcros...@codeaurora.org 
>> ;
>> nikola.te...@syrmia.com ; lldb-commits 
>> mailto:lldb-commits@lists.llvm.org>>;
>> liburd1...@outlook.com ; 
>> stefan.graen...@gmail.com ; 
>> ma...@braunis.de ;
>> nemanja.i@gmail.com ; 
>> simon.dar...@gmail.com ; Tozer, Stephen
>> mailto:stephen.to...@sony.com>>; 
>> alokkumar.sha...@amd.com ; 
>> s...@chromium.org ;
>> sourabhsingh.to...@amd.com ; Jackson, 
>> Chris mailto:chris.jack...@sony.com>>;
>> arpha...@gmail.com ; j...@us.ibm.com 
>> ; ...@gmail.com ;
>> horse10241...@gmail.com ; 
>> pengfei.w...@intel.com ; david.gr...@arm.com 
>> ;
>> higuox...@gmail.com ; ikud...@accesssoftek.com 
>> ; p8u8i7l5t1q9r8w3@ibm-
>> systems-z.slack.com ; Enciso, Carlos 
>> mailto:carlos.enc...@sony.com>>; llvm-
>> comm...@lists.llvm.org ; Cazalet-Hyams, 
>> Orlando mailto:orlando.hy...@sony.com>>;
>> aso...@cisco.com ; sani...@subpath.org 
>> ; si...@atanasyan.com 
>> ;
>> jrt...@jrtc27.com ; djordje.todoro...@syrmia.com 
>> ; ch.besson...@gmail.com 
>> ;
>> quentin.colom...@gmail.com ; 
>> akhu...@google.com ; ahee...@gmail.com 
>> ;
>> avl.laps...@gmail.com ; 
>> david.stenb...@ericsson.com ;
>> david.spick...@linaro.org ; 
>> dougp...@gmail.com ; bhuvanendra.kum...@amd.com 
>> ;
>> serhiy.re...@gmail.com ; 
>> jini.susan.geo...@gmail.com 
>> Subject: Re: [Lldb-commits] [PATCH] D91734: [FastISel] Flush local value
>> map on every instruction
>> 
>> Note, lldb has a bunch of special handling for line 0 code.  For instance,
>> when we are pushing a breakpoint past the prologue we will keep pushing it
>> forward over line number 0 lines.  Those are compiler generated and in
>> general people don't want to stop there.  Similarly, if you are stepping
>> through line 3 and the next line entry after 3 is line 0 we keep stepping
>> till we get to a non-zero line.
>> 
>> When the compiler is actually using line 0 to mean "compiler generated
>> code not really associated with a particular line, then I am pretty sure
>> the debugger has to be aware of this or debugging is going to be a bit
>> awkward...
>> 
>> I don't know if that's directly relevant to this bug, I haven't had time
>> to follow the whole discussion.  But I'm not convinced all the problems
>> with line 0 emission causing debugging oddities can be solved in the line
>> table generation.
>> 
>> Jim
> 
> Hi Jim,
> 
> This issue is not really "line 0 causing debugger oddities" so much as
> "line 0 attached to instructions that should have a real line number."
> 
> It's true that gdb's response to line 0 on the first instruction past
> the prologue_end seems a tad idiosyncratic, but if nothing else, it
> exposed an issue in the compiler that is worth solving.  There are
> clearly instructions attributed to line 0 that shouldn't be, and the
> goal here is to make that better.

That's great!  Getting all the instructions you can assigned correctly to real 
lines is worthy labor!  

Once you are all done with that work, given you really are using line 0 for 
real instances of compiler generated code that aren't attributable to any one 
line, stepping in gdb is going to look odd sometimes if gdb doesn't know to 
handle them.  It might be worth filing some bugs with gdb to cope with this 
situation (though its probably better to use examples where the line 0 is 
correctly attributed...)

Jim


> 
> Tha

Re: [Lldb-commits] [PATCH] D91734: [FastISel] Flush local value map on every instruction

[Jim Ingham via lldb-commits]

Note, lldb has a bunch of special handling for line 0 code.  For instance, when 
we are pushing a breakpoint past the prologue we will keep pushing it forward 
over line number 0 lines.  Those are compiler generated and in general people 
don't want to stop there.  Similarly, if you are stepping through line 3 and 
the next line entry after 3 is line 0 we keep stepping till we get to a 
non-zero line.  

When the compiler is actually using line 0 to mean "compiler generated code not 
really associated with a particular line, then I am pretty sure the debugger 
has to be aware of this or debugging is going to be a bit awkward...

I don't know if that's directly relevant to this bug, I haven't had time to 
follow the whole discussion.  But I'm not convinced all the problems with line 
0 emission causing debugging oddities can be solved in the line table 
generation.

Jim


> On Dec 3, 2020, at 10:33 AM, David Blaikie via Phabricator via lldb-commits 
>  wrote:
> 
> dblaikie added a comment.
> 
> In D91734#2431247 , @probinson wrote:
> 
>>> Sometihng like this seems plausible to me:
>> 
>> Yes, I was playing with essentially that exact patch last night.  It has no 
>> effect on the final assembly on its own, but combined with my patch it does.
> 
> It might have effects on assembly in other test cases, though. Could be worth 
> running it through a self-host or something to see what other changes it 
> causes and whether they're desirable.
> 
>>> (a more general fix (that would cover cases where the instruction really 
>>> has no location) might be to propagate locations from the first instruction 
>>> in a basic block with a location back up to the start of the basic block - 
>>> I forget if we've considered/tried that before)
>> 
>> We have, but that without flushing the map on every instruction, so it 
>> caught materialization instructions that didn't actually belong to that IR 
>> instruction.  The tactic would likely be more reasonable in conjunction with 
>> my patch.
> 
> (oh, when I was saying that I didn't really think - the materialization in 
> this case wasn't necessarily on a BB boundary - so I guess my suggestion 
> amounts to possibly never using line 0 (unless it's the only location in a 
> whole BB), instead back or forward propagating surrounding locations over any 
> line 0 - and that doesn't sound right when I put it that way)
> 
> But yeah, maybe some amount of it could be done around the flushing thing.
> 
> (FWIW, about this patch in general, I do worry a bit about this being a 
> debug-info motivated optimization decision (even if that decision is applied 
> uniformly/not just when debug info is enabled) - you mention this might have 
> positive performance features due to smaller register live ranges, but also 
> possibly negative ones rematerializing the same constant (" however, only 
> about 5% of those values
> were reused in an experimental self-build of clang.") - do you have 
> performance measurements/benchmarks related to this change? I guess it didn't 
> show up in the perf bot profiles upstream at least)
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D91734/new/
> 
> https://reviews.llvm.org/D91734
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

[Lldb-commits] [lldb] 5a4b2e1 - The AssertRecognizer used the module from a frames SC without checking it was non-null.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-11-13T11:41:32-08:00
New Revision: 5a4b2e1541f399c146a4ef5cf8f6aaf8b258a77b

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

LOG: The AssertRecognizer used the module from a frames SC without checking it 
was non-null.

I only have a crash report for this.  I could reproduce it with a slightly older
lldb by running an expression that called pthread_kill, but we started making 
modules
for our expression JIT code, so that no longer triggers the bug.  I can't think 
of another
good way to test it but the fix is obvious.

Added: 


Modified: 
lldb/source/Target/AssertFrameRecognizer.cpp

Removed: 




diff  --git a/lldb/source/Target/AssertFrameRecognizer.cpp 
b/lldb/source/Target/AssertFrameRecognizer.cpp
index fe5fa3a362f8..cb671040d14f 100644
--- a/lldb/source/Target/AssertFrameRecognizer.cpp
+++ b/lldb/source/Target/AssertFrameRecognizer.cpp
@@ -130,7 +130,8 @@ AssertFrameRecognizer::RecognizeFrame(lldb::StackFrameSP 
frame_sp) {
 SymbolContext sym_ctx =
 prev_frame_sp->GetSymbolContext(eSymbolContextEverything);
 
-if (!sym_ctx.module_sp->GetFileSpec().FileEquals(location.module_spec))
+if (!sym_ctx.module_sp ||
+!sym_ctx.module_sp->GetFileSpec().FileEquals(location.module_spec))
   continue;
 
 ConstString func_name = sym_ctx.GetFunctionName();



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

[Lldb-commits] [lldb] 32a85b2 - This is a preliminary version of the test for https://reviews.llvm.org/D88483.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-10-29T16:39:35-07:00
New Revision: 32a85b268a010035e81646541ac1c9675da6cb2e

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

LOG: This is a preliminary version of the test for 
https://reviews.llvm.org/D88483.

The test can be cleaned up a bit, but this should be good to see why the
Debian bot is failing...

Added: 


Modified: 
lldb/test/API/functionalities/type_get_module/TestTypeGetModule.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/type_get_module/TestTypeGetModule.py 
b/lldb/test/API/functionalities/type_get_module/TestTypeGetModule.py
index e6acecc76e17..ccab396455ea 100644
--- a/lldb/test/API/functionalities/type_get_module/TestTypeGetModule.py
+++ b/lldb/test/API/functionalities/type_get_module/TestTypeGetModule.py
@@ -13,10 +13,56 @@ class TestTypeGetModule(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
 
+def find_module(self, target, name):
+num_modules = target.GetNumModules()
+index = 0
+result = lldb.SBModule()
+
+while index < num_modules:
+module = target.GetModuleAtIndex(index)
+if module.GetFileSpec().GetFilename() == name:
+result = module
+break
+
+index += 1
+
+return result
+
+def find_comp_unit(self, exe_module, name):
+num_comp_units = exe_module.GetNumCompileUnits()
+index = 0
+result = lldb.SBCompileUnit()
+
+while index < num_comp_units:
+comp_unit = exe_module.GetCompileUnitAtIndex(index)
+if comp_unit.GetFileSpec().GetFilename() == name:
+result = comp_unit
+break
+
+index += 1
+
+return result
+
+def find_type(self, type_list, name):
+num_types = type_list.GetSize()
+index = 0
+result = lldb.SBType()
+
+while index < num_types:
+type = type_list.GetTypeAtIndex(index)
+if type.GetName() == name:
+result = type
+break
+
+index += 1
+
+return result
+
 def test(self):
 self.build()
 target  = lldbutil.run_to_breakpoint_make_target(self)
-exe_module = target.GetModuleAtIndex(0)
+exe_module = self.find_module(target, 'a.out')
+self.assertTrue(exe_module.IsValid())
 
 type1_name = 'compile_unit1_type'
 type2_name = 'compile_unit2_type'
@@ -24,13 +70,19 @@ def test(self):
 num_comp_units = exe_module.GetNumCompileUnits()
 self.assertEqual(num_comp_units, 3)
 
-comp_unit = exe_module.GetCompileUnitAtIndex(1)
-type_name = comp_unit.GetTypes().GetTypeAtIndex(0).GetName()
-self.assertEqual(type_name, type1_name)
+comp_unit = self.find_comp_unit(exe_module, 'compile_unit1.c')
+self.assertTrue(comp_unit.IsValid())
+
+cu_type = self.find_type(comp_unit.GetTypes(), type1_name)
+self.assertTrue(cu_type.IsValid())
+self.assertEqual(cu_type.GetName(), type1_name)
+
+comp_unit = self.find_comp_unit(exe_module, 'compile_unit2.c')
+self.assertTrue(comp_unit.IsValid())
 
-comp_unit = exe_module.GetCompileUnitAtIndex(2)
-type_name = comp_unit.GetTypes().GetTypeAtIndex(0).GetName()
-self.assertEqual(type_name, type2_name)
+cu_type = self.find_type(comp_unit.GetTypes(), type2_name)
+self.assertTrue(cu_type.IsValid())
+self.assertEqual(cu_type.GetName(), type2_name)
 
 type1 = target.FindFirstType(type1_name)
 self.assertTrue(type1.IsValid())



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

[Lldb-commits] [lldb] fa5a132 - Provide a reasonable value for PATH_MAX if the lldb headers don't provide it.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-10-29T15:02:51-07:00
New Revision: fa5a13276764a2657b3571fa3c57b07ee5d2d661

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

LOG: Provide a reasonable value for PATH_MAX if the lldb headers don't provide 
it.

Added: 


Modified: 
lldb/test/API/api/multithreaded/test_stop-hook.cpp.template

Removed: 




diff  --git a/lldb/test/API/api/multithreaded/test_stop-hook.cpp.template 
b/lldb/test/API/api/multithreaded/test_stop-hook.cpp.template
index 8b60421ec301..393e717cceb5 100644
--- a/lldb/test/API/api/multithreaded/test_stop-hook.cpp.template
+++ b/lldb/test/API/api/multithreaded/test_stop-hook.cpp.template
@@ -12,6 +12,10 @@
 
 #include "common.h"
 
+#if !defined(PATH_MAX)
+#define PATH_MAX 4096
+#endif
+
 using namespace lldb;
 
 void test(SBDebugger &dbg, std::vector args) {



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

[Lldb-commits] [lldb] c8c07b7 - Use !hasLocalLinkage instead of listing the symbol types

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-10-29T14:44:06-07:00
New Revision: c8c07b76b2cf2ada8e7ec132f7f57b97d76743cf

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

LOG: Use !hasLocalLinkage instead of listing the symbol types
we should be exporting one by one.

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

Added: 


Modified: 
lldb/source/Expression/IRExecutionUnit.cpp

Removed: 




diff  --git a/lldb/source/Expression/IRExecutionUnit.cpp 
b/lldb/source/Expression/IRExecutionUnit.cpp
index e3c9c1d7fdf5..538935da52ee 100644
--- a/lldb/source/Expression/IRExecutionUnit.cpp
+++ b/lldb/source/Expression/IRExecutionUnit.cpp
@@ -328,8 +328,7 @@ void IRExecutionUnit::GetRunnableInfo(Status &error, 
lldb::addr_t &func_addr,
 if (function.isDeclaration() || function.hasPrivateLinkage())
   continue;
 
-const bool external =
-function.hasExternalLinkage() || function.hasLinkOnceODRLinkage();
+const bool external = !function.hasLocalLinkage();
 
 void *fun_ptr = m_execution_engine_up->getPointerToFunction(&function);
 



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

[Lldb-commits] [lldb] a37672e - Mark the execution of stop-hooks as non-interactive.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-10-29T14:41:53-07:00
New Revision: a37672e2db7377681d996834a0c3073c9838a549

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

LOG: Mark the execution of stop-hooks as non-interactive.

The intention is not to allow stop-hook commands to query the
user, so this is correct.  It also works around a deadlock in
switching to the Python Session to execute python based commands
in the stop hook when the Debugger stdin is backed by a FILE *.

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

Added: 
lldb/test/API/api/multithreaded/some_cmd.py
lldb/test/API/api/multithreaded/test_stop-hook.cpp.template

Modified: 
lldb/packages/Python/lldbsuite/test/lldbtest.py
lldb/source/Interpreter/CommandInterpreter.cpp
lldb/source/Target/Target.cpp
lldb/test/API/api/multithreaded/TestMultithreaded.py

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py 
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index 69da3914f1f2..81110f9f80c4 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -1927,6 +1927,7 @@ def generateSource(self, source):
 header.startswith("SB") and header.endswith(".h"))]
 includes = '\n'.join(list)
 new_content = content.replace('%include_SB_APIs%', includes)
+new_content = new_content.replace('%SOURCE_DIR%', self.getSourceDir())
 src = os.path.join(self.getBuildDir(), source)
 with open(src, 'w') as f:
 f.write(new_content)

diff  --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index c6031f571311..d6b4b89da1c9 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -2307,6 +2307,8 @@ void CommandInterpreter::HandleCommands(const StringList 
&commands,
 }
 
 CommandReturnObject tmp_result(m_debugger.GetUseColor());
+tmp_result.SetInteractive(result.GetInteractive());
+
 // If override_context is not NULL, pass no_context_switching = true for
 // HandleCommand() since we updated our context already.
 

diff  --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index 6b8a053b972e..7c78b4a84c41 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -3286,6 +3286,7 @@ Target::StopHookCommandLine::HandleStop(ExecutionContext 
&exc_ctx,
 
   CommandReturnObject result(false);
   result.SetImmediateOutputStream(output_sp);
+  result.SetInteractive(false);
   Debugger &debugger = exc_ctx.GetTargetPtr()->GetDebugger();
   CommandInterpreterRunOptions options;
   options.SetStopOnContinue(true);

diff  --git a/lldb/test/API/api/multithreaded/TestMultithreaded.py 
b/lldb/test/API/api/multithreaded/TestMultithreaded.py
index 436f645e6521..60c2c3b372cb 100644
--- a/lldb/test/API/api/multithreaded/TestMultithreaded.py
+++ b/lldb/test/API/api/multithreaded/TestMultithreaded.py
@@ -23,9 +23,19 @@ def setUp(self):
 self.generateSource('test_listener_event_description.cpp')
 self.generateSource('test_listener_event_process_state.cpp')
 self.generateSource('test_listener_resume.cpp')
+self.generateSource('test_stop-hook.cpp')
 
 mydir = TestBase.compute_mydir(__file__)
 
+@skipIfRemote
+@skipIfNoSBHeaders
+# clang-cl does not support throw or catch (llvm.org/pr24538)
+@skipIfWindows
+def test_python_stop_hook(self):
+"""Test that you can run a python command in a stop-hook when stdin is 
File based. """
+self.build_and_test('driver.cpp test_stop-hook.cpp',
+'test_python_stop_hook')
+
 @skipIfRemote
 @skipIfNoSBHeaders
 # clang-cl does not support throw or catch (llvm.org/pr24538)

diff  --git a/lldb/test/API/api/multithreaded/some_cmd.py 
b/lldb/test/API/api/multithreaded/some_cmd.py
new file mode 100644
index ..8db4b5f7b432
--- /dev/null
+++ b/lldb/test/API/api/multithreaded/some_cmd.py
@@ -0,0 +1,33 @@
+""" Test command for checking the Python commands can run in a stop-hook """
+import lldb
+
+did_run = False
+
+class SomeCommand:
+def __init__(self, debugger, unused):
+self.dbg = debugger
+def __call__(self, debugger, command, exe_ctx, result):
+global did_run
+did_run = True
+result.PutCString("some output\n")
+
+def get_short_help(self):
+return "Test command - sets a variable."
+
+class OtherCommand:
+def __init__(self, debugger, unused):
+self.dbg = debugger
+def __call__(self, debugger, command, exe_ctx, result):
+global did_run
+if did_run:
+result.SetStatus(lldb.eReturnStatusSuccessFinishNoRe

[Lldb-commits] [lldb] 6754caa - Add an SB API to get the SBTarget from an SBBreakpoint

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-10-15T14:28:44-07:00
New Revision: 6754caa9bf21a759c4080a797f23e2b7a77a71e1

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

LOG: Add an SB API to get the SBTarget from an SBBreakpoint

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

Added: 


Modified: 
lldb/bindings/interface/SBBreakpoint.i
lldb/include/lldb/API/SBBreakpoint.h
lldb/source/API/SBBreakpoint.cpp
lldb/test/API/python_api/breakpoint/TestBreakpointAPI.py

Removed: 




diff  --git a/lldb/bindings/interface/SBBreakpoint.i 
b/lldb/bindings/interface/SBBreakpoint.i
index e386ace9dee8..696795241b11 100644
--- a/lldb/bindings/interface/SBBreakpoint.i
+++ b/lldb/bindings/interface/SBBreakpoint.i
@@ -100,6 +100,9 @@ public:
 void
 ClearAllBreakpointSites ();
 
+lldb::SBTarget
+GetTarget() const;
+  
 lldb::SBBreakpointLocation
 FindLocationByAddress (lldb::addr_t vm_addr);
 

diff  --git a/lldb/include/lldb/API/SBBreakpoint.h 
b/lldb/include/lldb/API/SBBreakpoint.h
index 39a021145fb7..e13dbc5c3516 100644
--- a/lldb/include/lldb/API/SBBreakpoint.h
+++ b/lldb/include/lldb/API/SBBreakpoint.h
@@ -42,6 +42,8 @@ class LLDB_API SBBreakpoint {
 
   void ClearAllBreakpointSites();
 
+  lldb::SBTarget GetTarget() const;
+
   lldb::SBBreakpointLocation FindLocationByAddress(lldb::addr_t vm_addr);
 
   lldb::break_id_t FindLocationIDByAddress(lldb::addr_t vm_addr);

diff  --git a/lldb/source/API/SBBreakpoint.cpp 
b/lldb/source/API/SBBreakpoint.cpp
index 96b77bd8539e..96ae305ffce5 100644
--- a/lldb/source/API/SBBreakpoint.cpp
+++ b/lldb/source/API/SBBreakpoint.cpp
@@ -81,6 +81,16 @@ bool SBBreakpoint::operator!=(const lldb::SBBreakpoint &rhs) 
{
   return m_opaque_wp.lock() != rhs.m_opaque_wp.lock();
 }
 
+SBTarget SBBreakpoint::GetTarget() const {
+  LLDB_RECORD_METHOD_CONST_NO_ARGS(lldb::SBTarget, SBBreakpoint, GetTarget);
+
+  BreakpointSP bkpt_sp = GetSP();
+  if (bkpt_sp)
+return LLDB_RECORD_RESULT(SBTarget(bkpt_sp->GetTargetSP()));
+
+  return LLDB_RECORD_RESULT(SBTarget());
+}
+
 break_id_t SBBreakpoint::GetID() const {
   LLDB_RECORD_METHOD_CONST_NO_ARGS(lldb::break_id_t, SBBreakpoint, GetID);
 
@@ -987,6 +997,7 @@ void RegisterMethods(Registry &R) {
SBBreakpoint, operator==,(const lldb::SBBreakpoint &));
   LLDB_REGISTER_METHOD(bool,
SBBreakpoint, operator!=,(const lldb::SBBreakpoint &));
+  LLDB_REGISTER_METHOD_CONST(lldb::SBTarget, SBBreakpoint, GetTarget, ());
   LLDB_REGISTER_METHOD_CONST(lldb::break_id_t, SBBreakpoint, GetID, ());
   LLDB_REGISTER_METHOD_CONST(bool, SBBreakpoint, IsValid, ());
   LLDB_REGISTER_METHOD_CONST(bool, SBBreakpoint, operator bool, ());

diff  --git a/lldb/test/API/python_api/breakpoint/TestBreakpointAPI.py 
b/lldb/test/API/python_api/breakpoint/TestBreakpointAPI.py
index 1c0c334fbeeb..80324ee61b70 100644
--- a/lldb/test/API/python_api/breakpoint/TestBreakpointAPI.py
+++ b/lldb/test/API/python_api/breakpoint/TestBreakpointAPI.py
@@ -66,6 +66,9 @@ def test_target_delete(self):
 location = breakpoint.GetLocationAtIndex(0)
 self.assertTrue(location.IsValid())
 
+# Make sure the breakpoint's target is right:
+self.assertEqual(target, breakpoint.GetTarget(), "Breakpoint reports 
its target correctly")
+
 self.assertTrue(self.dbg.DeleteTarget(target))
 self.assertFalse(breakpoint.IsValid())
 self.assertFalse(location.IsValid())



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

[Lldb-commits] [lldb] a68ffb1 - Change the default handling of SIGCONT to nosuppress/nostop/notify

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-10-08T15:24:19-07:00
New Revision: a68ffb19d392c6d52f6e42925217a77b4cd71cee

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

LOG: Change the default handling of SIGCONT to nosuppress/nostop/notify

Except for the few people actually debugging shells, stopping on a
SIGCONT doesn't add any value.  And for people trying to run tests
under the debugger, stopping here is actively inconvenient.  So this
patch switches the default behavior to not stop.

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

Added: 


Modified: 
lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
lldb/source/Target/UnixSignals.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp 
b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
index 4dd619e3bade..568939029aee 100644
--- a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
+++ b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
@@ -37,7 +37,7 @@ void LinuxSignals::Reset() {
   AddSignal(16, "SIGSTKFLT", false, true, true, "stack fault");
   AddSignal(17, "SIGCHLD", false, false, true, "child status has changed",
 "SIGCLD");
-  AddSignal(18, "SIGCONT", false, true, true, "process continue");
+  AddSignal(18, "SIGCONT", false, false, true, "process continue");
   AddSignal(19, "SIGSTOP", true, true, true, "process stop");
   AddSignal(20, "SIGTSTP", false, true, true, "tty stop");
   AddSignal(21, "SIGTTIN", false, true, true, "background tty read");

diff  --git a/lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp 
b/lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
index 8f75844277c0..17c238c04453 100644
--- a/lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
+++ b/lldb/source/Plugins/Process/Utility/MipsLinuxSignals.cpp
@@ -45,7 +45,7 @@ void MipsLinuxSignals::Reset() {
 "SIGPOLL");
   AddSignal(23, "SIGSTOP", true, true, true, "process stop");
   AddSignal(24, "SIGTSTP", false, true, true, "tty stop");
-  AddSignal(25, "SIGCONT", false, true, true, "process continue");
+  AddSignal(25, "SIGCONT", false, false, true, "process continue");
   AddSignal(26, "SIGTTIN", false, true, true, "background tty read");
   AddSignal(27, "SIGTTOU", false, true, true, "background tty write");
   AddSignal(28, "SIGVTALRM", false, true, true, "virtual time alarm");

diff  --git a/lldb/source/Target/UnixSignals.cpp 
b/lldb/source/Target/UnixSignals.cpp
index f6b4e82a88ed..84a2ef67ac29 100644
--- a/lldb/source/Target/UnixSignals.cpp
+++ b/lldb/source/Target/UnixSignals.cpp
@@ -94,7 +94,7 @@ void UnixSignals::Reset() {
   AddSignal(16, "SIGURG", false,false,  false,  "urgent condition 
on IO channel");
   AddSignal(17, "SIGSTOP",true, true,   true,   "sendable stop 
signal not from tty");
   AddSignal(18, "SIGTSTP",false,true,   true,   "stop signal from 
tty");
-  AddSignal(19, "SIGCONT",false,true,   true,   "continue a 
stopped process");
+  AddSignal(19, "SIGCONT",false,false,  true,   "continue a 
stopped process");
   AddSignal(20, "SIGCHLD",false,false,  false,  "to parent on 
child stop or exit");
   AddSignal(21, "SIGTTIN",false,true,   true,   "to readers 
process group upon background tty read");
   AddSignal(22, "SIGTTOU",false,true,   true,   "to readers 
process group upon background tty write");



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

[Lldb-commits] [lldb] 81b11c9 - Fix a macOS build break caused by 3dfb94986170.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-10-07T15:01:27-07:00
New Revision: 81b11c91070f3a969b64b2c2e6011b02450fa75f

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

LOG: Fix a macOS build break caused by 3dfb94986170.

Added: 


Modified: 

lldb/source/Plugins/Platform/MacOSX/objcxx/PlatformiOSSimulatorCoreSimulatorSupport.mm

Removed: 




diff  --git 
a/lldb/source/Plugins/Platform/MacOSX/objcxx/PlatformiOSSimulatorCoreSimulatorSupport.mm
 
b/lldb/source/Plugins/Platform/MacOSX/objcxx/PlatformiOSSimulatorCoreSimulatorSupport.mm
index cfd44f9ae5ce..92bf716599b0 100644
--- 
a/lldb/source/Plugins/Platform/MacOSX/objcxx/PlatformiOSSimulatorCoreSimulatorSupport.mm
+++ 
b/lldb/source/Plugins/Platform/MacOSX/objcxx/PlatformiOSSimulatorCoreSimulatorSupport.mm
@@ -415,8 +415,9 @@ static Status HandleFileAction(ProcessLaunchInfo 
&launch_info,
   secondary_fd =
   launch_info.GetPTY().OpenSecondary(O_RDWR, nullptr, 0);
 if (secondary_fd == PseudoTerminal::invalid_fd) {
+  std::string secondary_path = secondary_spec.GetPath();
   error.SetErrorStringWithFormat(
-  "unable to open secondary pty '%s'", secondary_path);
+  "unable to open secondary pty '%s'", secondary_path.c_str());
   return error; // Failure
 }
 [options setValue:[NSNumber numberWithInteger:secondary_fd]



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

Re: [Lldb-commits] [PATCH] D88840: [dotest] Simplify logic to find the Python path

[Jim Ingham via lldb-commits]

> On Oct 6, 2020, at 8:40 AM, Pavel Labath via Phabricator via lldb-commits 
>  wrote:
> 
> labath added a comment.
> 
> In D88840#2314587 , @rupprecht wrote:
> 
>> In D88840#2313331 , @kastiglione 
>> wrote:
>> 
>>> About `-P`, the man page for `lldb` and the driver's `Options.td` say it:
>>> 
 Prints out the path to the lldb.py file for this version of lldb.
>>> 
>>> Should it do just that? If so this can be simplified further.
>> 
>> It can print the path, or it can print `` if e.g. lldb 
>> wasn't built with python support or has some non-standard python setup. So I 
>> think this is basically as simple as the parsing can get.
> 
> One way this could be simplified further is to ditch `-P` and pass down the 
> appropriate value from cmake/lit.

-P is not just for running the testsuite, it’s a way for users to set up their 
PYTHONPATH for lldb standalone scripts.  So far as I can see at present it’s 
only tested by dotest relying on its having a good value.  So if we aren’t 
going to use it in dotest we need to write some explicit tests for it.

Jim


> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D88840/new/
> 
> https://reviews.llvm.org/D88840
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

[Lldb-commits] [lldb] be66987 - Fix raciness in the StopHook check for "has the target run".

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-10-05T15:44:28-07:00
New Revision: be66987e2047636d9ed9d2a4d88b762d59ae88f2

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

LOG: Fix raciness in the StopHook check for "has the target run".

This was looking at the privateState, but it's possible that
the actual process has started up and then stopped again by the
time we get to the check, which would lead us to get out of running
the stop hooks too early.

Instead we need to track the intention of the stop hooks directly.

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

Added: 


Modified: 
lldb/include/lldb/Target/Target.h
lldb/source/Target/Process.cpp
lldb/source/Target/Target.cpp
lldb/test/API/commands/target/stop-hooks/TestStopHookScripted.py

Removed: 




diff  --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index 94c6ebeac10d..7ee27a9776d5 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -1145,6 +1145,11 @@ class Target : public 
std::enable_shared_from_this,
 virtual ~StopHook() = default;
 
 enum class StopHookKind  : uint32_t { CommandBased = 0, ScriptBased };
+enum class StopHookResult : uint32_t {
+  KeepStopped = 0,
+  RequestContinue,
+  AlreadyContinued
+};
 
 lldb::TargetSP &GetTarget() { return m_target_sp; }
 
@@ -1160,8 +1165,8 @@ class Target : public 
std::enable_shared_from_this,
 // with a reason" thread.  It should add to the stream whatever text it
 // wants to show the user, and return False to indicate it wants the target
 // not to stop.
-virtual bool HandleStop(ExecutionContext &exe_ctx,
-lldb::StreamSP output) = 0;
+virtual StopHookResult HandleStop(ExecutionContext &exe_ctx,
+  lldb::StreamSP output) = 0;
 
 // Set the Thread Specifier.  The stop hook will own the thread specifier,
 // and is responsible for deleting it when we're done.
@@ -1201,8 +1206,8 @@ class Target : public 
std::enable_shared_from_this,
 void SetActionFromString(const std::string &strings);
 void SetActionFromStrings(const std::vector &strings);
 
-bool HandleStop(ExecutionContext &exc_ctx,
-lldb::StreamSP output_sp) override;
+StopHookResult HandleStop(ExecutionContext &exc_ctx,
+  lldb::StreamSP output_sp) override;
 void GetSubclassDescription(Stream *s,
 lldb::DescriptionLevel level) const override;
 
@@ -1219,7 +1224,8 @@ class Target : public 
std::enable_shared_from_this,
   class StopHookScripted : public StopHook {
   public:
 virtual ~StopHookScripted() = default;
-bool HandleStop(ExecutionContext &exc_ctx, lldb::StreamSP output) override;
+StopHookResult HandleStop(ExecutionContext &exc_ctx,
+  lldb::StreamSP output) override;
 
 Status SetScriptCallback(std::string class_name,
  StructuredData::ObjectSP extra_args_sp);
@@ -1254,7 +1260,9 @@ class Target : public 
std::enable_shared_from_this,
   /// remove the stop hook, as it will also reset the stop hook counter.
   void UndoCreateStopHook(lldb::user_id_t uid);
 
-  void RunStopHooks();
+  // Runs the stop hooks that have been registered for this target.
+  // Returns true if the stop hooks cause the target to resume.
+  bool RunStopHooks();
 
   size_t GetStopHookSize();
 

diff  --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index c602511daedc..490ca45bfee2 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -4178,8 +4178,7 @@ void Process::ProcessEventData::DoOnRemoval(Event 
*event_ptr) {
   // public (or SyncResume) broadcasters.  StopHooks are just for
   // real public stops.  They might also restart the target,
   // so watch for that.
-  process_sp->GetTarget().RunStopHooks();
-  if (process_sp->GetPrivateState() == eStateRunning)
+  if (process_sp->GetTarget().RunStopHooks())
 SetRestarted(true);
 }
   }

diff  --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index a5250ddcef74..49af6c297cbc 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -2541,25 +2541,26 @@ void Target::SetAllStopHooksActiveState(bool 
active_state) {
   }
 }
 
-void Target::RunStopHooks() {
+bool Target::RunStopHooks() {
   if (m_suppress_stop_hooks)
-return;
+return false;
 
   if (!m_process_sp)
-return;
+return false;
 
   // Somebody might have restarted the process:
+  // Still return false, the return value is about US restarting the target.
   if (m_process_sp->GetState() != eStateStopped)
-retu

Re: [Lldb-commits] [PATCH] D88516: [lldb] Add a "design" section to the documentation.

[Jim Ingham via lldb-commits]

Architecture is more specific to the structural aspect of a thing, whereas 
Design is more general.  For instance, the rules for the SB API don’t really 
seem like a description of an Architecture, but more some general principles 
for doing the thing.

Jim

> On Oct 1, 2020, at 4:25 PM, Adrian Prantl via Phabricator 
>  wrote:
> 
> aprantl added a comment.
> 
> What's the difference between design/ and architecture/? These sounds like 
> synonyms to me.
> 
> 
> Repository:
>  rLLDB LLDB
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D88516/new/
> 
> https://reviews.llvm.org/D88516
> 

___
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]

Thanks for the info…

We’re running in sync mode, so for Continue to return before the process is all 
the way stopped, Process::ResumeSynchronous() must be bobbling the case where a 
stop event that resumes the process comes in.  The only way I can see that 
happening is if Process::PrivateResume can return before setting the private 
state to eStateRunning.  But only when something gets a chance to time out 
somewhere along the line.

I’ve been looking but I haven’t found anything relevant along this code path.  
There is one hard-coded timeout along this path, the 5 second wait between 
sending the eBroadcastBitAsyncContinue with the continue packet to the 
gdb-remote async thread and receiving the ack back (in 
ProcessGDBRemote::DoResume).  But if that timed out it would write a 
“gdb-remote process” log message: "Resume timed out”.  The process log is on, I 
see other output from it, but I don’t see that message in the failure 
transcript.

Weird.

Jim

> On Oct 1, 2020, at 5:26 AM, Raphael “Teemperor” Isemann  
> wrote:
> 
> +1, I have two machines with very similar setup where only the one that is 
> under heavy load sees the test failures.
> 
> - Raphael
> 
>> On 1 Oct 2020, at 14:24, Pavel Labath  wrote:
>> 
>> On 30/09/2020 23:21, Jim Ingham wrote:
>>> The test doesn’t seem to be flakey in the “run it a bunch of times and
>>> it will eventually fail” type flakey.  I ran the test 200 times on my
>>> machine and didn’t get a failure.
>> 
>> Actually, it seems like exactly the typical kind of flaky test to me --
>> it mostly works when run on its own, but starts failing as soon as the
>> system comes under load.
>> 
>> It didn't fail for me either for over 100 iterations. However, as soon
>> as I cranked up the cpu load (compiling llvm is good at that), it failed
>> almost immediately.
>> 
>> It also doesn't seem to be related to the way the stop hook resumes the
>> process.
>> 
>> is one example where the auto_continue version of the test fails, and I
>> have seen both tests fail on my machine.
>> 
>> I have some traces of failing and successful runs of the test (will send
>> them to you in a private email). I didn't dive too deeply, but the
>> problem does not seem to be related to python stop hooks. It looks more
>> like a general stop hook bug, which we've had problems with in the past.
>> 
>> The problems seems to be that the process.Continue() on the main thread
>> returns early, and so the subsequent checks (for the topmost frame etc.)
>> execute concurrently with the "step out" action. In the "Failure" file
>> I'll send you you can see that (line 9222) SBFrame::GetFunctionName is
>> called before the inferior process stops in the main function (the
>> processing of that happens immediately after that line, on the
>> "intern-state" thread).
>> 
>> 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.""

[Jim Ingham via lldb-commits]

The test doesn’t seem to be flakey in the “run it a bunch of times and it will 
eventually fail” type flakey.  I ran the test 200 times on my machine and 
didn’t get a failure.

Another weird fact is that there are two ways to auto-continue from a 
stop-hook, either pass the —auto-continue flag when adding the stop hook, or 
returning False from the handle_stop.  All the failures that I have seen on the 
bots are the “return False” test, the auto-continue test never fails.  
That’s relevant because the failure is that “returning false from the stop 
hook” doesn’t cause us to continue.

Those two scenario’s differ in only two ways: 

1) In the “return False” case, we have to get the false result from the return 
of the callback invocation in Python through the ScriptInterpreter and back to 
C.  In the “auto-continue” case we’re just reading a flag in the StopHook.

2) When we go to decide whether to auto-continue or not we do:

  if (!somebody_restarted && ((hooks_ran && !should_stop) || auto_continue))
m_process_sp->PrivateResume();

where the auto_continue case is controlled by the setting of the auto_continue 
flag, but the handle_stop return is computed from the handle_stop return value. 
 If we’re fetching the return value correctly, then I can’t see how the “return 
False” could be flakey and not the “auto-continue” one.

When I resubmitted this patch, I added a print of the return value from the 
stop hook’s handle_stop.  Even in the failing case the hook is running and 
reports that it is returning false from the Python side of the hook correctly.  
So we’re right up to there.  After that I don’t have any visibility into why 
this is failing.

BTW, another obvious cause of “flakiness” is if you have uninitialized 
variables lying around, but there aren’t that many variables in this code and 
so far as I can see everything is initialized before use.

Anyway, if people don’t mind, I’ll check in a change that makes the stop hooks 
a little noisier by reporting the result passing through the ScriptInterpreter 
to RunStopHooks.  That will come to the test log, so with any luck I’ll be able 
to narrow down the cause of the failure that way.

Jim

> On Sep 30, 2020, at 12:01 PM, Pavel Labath  wrote:
> 
> 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] [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
>>>  

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 &error
>> +)
>> +{
>> +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 s

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

[Jim Ingham via lldb-commits]

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 &error
+)
+{
+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 (callback_func.IsAllocated()) {
+  if (auto args_info = callback_func.GetArgInfo()) {
+size_t num_args = (*args_info).max_positional_args; 
+if (num_args != 2) {
+  error.SetErrorStringWithFormat("Wrong number of args for "
+  "handle_stop callback, should be 2 (excluding self), got: %d", 
+  num_args);
+  Py_RETURN_NONE;
+} else
+  return result.release();
+  } else {
+error.SetErrorString("Couldn't get num arguments for handle_stop "
+ "callback.");
+Py_RETURN_NONE;
+  }
+  return result.release();
+}
+else {
+  error

[Lldb-commits] [lldb] b65966c - Add the ability to write target stop-hooks using the ScriptInterpreter.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-09-25T15:44:55-07:00
New Revision: b65966cff65bfb66de59621347ffd97238d3f645

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

LOG: Add the ability to write target stop-hooks using the ScriptInterpreter.

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

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..9e84b341d1a6 100644
--- a/lldb/bindings/python/python-wrapper.swig
+++ b/lldb/bindings/python/python-wrapper.swig
@@ -468,6 +468,123 @@ 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 &error
+)
+{
+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 (callback_func.IsAllocated()) {
+  if (auto args_info = callback_func.GetArgInfo()) {
+if ((*args_info).max_positional_args < 2) {
+  error.SetErrorStringWithFormat("Wrong number of args for "
+  "handle_stop callback, should be 2 (excluding self), got: %d", 
+  (*args_info).max_positional_args);
+} else
+  return result.release();
+  } else {
+error.SetErrorString("Couldn't get num arguments for handle_stop "
+ "callback.");
+  }
+  return result.release();
+}
+else {
+  error.SetErrorStringWithFormat("Class \"%s\" is missing the required 
"
+ "handle_stop callback.");
+  result.release();
+}
+}
+Py_RETURN_NONE;
+}
+
+SWIGEXPORT bool
+LLDBSwigPythonStopHookCallHandleStop
+(
+void *implementor,
+lldb::ExecutionContextRefSP exc_ctx_sp,
+lld

[Lldb-commits] [lldb] 3726ac4 - Add `breakpoint delete --disabled`: deletes all disabled breakpoints.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-09-23T11:35:11-07:00
New Revision: 3726ac41e9e00d2f6f87779b68f91ea264223c8a

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

LOG: Add `breakpoint delete --disabled`: deletes all disabled breakpoints.

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

Added: 


Modified: 
lldb/source/Commands/CommandObjectBreakpoint.cpp
lldb/source/Commands/Options.td

lldb/test/API/functionalities/breakpoint/breakpoint_command/TestBreakpointCommand.py

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectBreakpoint.cpp 
b/lldb/source/Commands/CommandObjectBreakpoint.cpp
index 023ba208176a..0844c56cef2f 100644
--- a/lldb/source/Commands/CommandObjectBreakpoint.cpp
+++ b/lldb/source/Commands/CommandObjectBreakpoint.cpp
@@ -1423,7 +1423,8 @@ class CommandObjectBreakpointDelete : public 
CommandObjectParsed {
 
   class CommandOptions : public Options {
   public:
-CommandOptions() : Options(), m_use_dummy(false), m_force(false) {}
+CommandOptions() : Options(), m_use_dummy(false), m_force(false),
+  m_delete_disabled(false) {}
 
 ~CommandOptions() override = default;
 
@@ -1440,6 +1441,10 @@ class CommandObjectBreakpointDelete : public 
CommandObjectParsed {
   case 'D':
 m_use_dummy = true;
 break;
+
+  case 'd':
+m_delete_disabled = true;
+break;
 
   default:
 llvm_unreachable("Unimplemented option");
@@ -1451,6 +1456,7 @@ class CommandObjectBreakpointDelete : public 
CommandObjectParsed {
 void OptionParsingStarting(ExecutionContext *execution_context) override {
   m_use_dummy = false;
   m_force = false;
+  m_delete_disabled = false;
 }
 
 llvm::ArrayRef GetDefinitions() override {
@@ -1460,16 +1466,18 @@ class CommandObjectBreakpointDelete : public 
CommandObjectParsed {
 // Instance variables to hold the values for command options.
 bool m_use_dummy;
 bool m_force;
+bool m_delete_disabled;
   };
 
 protected:
   bool DoExecute(Args &command, CommandReturnObject &result) override {
 Target &target = GetSelectedOrDummyTarget(m_options.m_use_dummy);
-
+result.Clear();
+
 std::unique_lock lock;
 target.GetBreakpointList().GetListMutex(lock);
 
-const BreakpointList &breakpoints = target.GetBreakpointList();
+BreakpointList &breakpoints = target.GetBreakpointList();
 
 size_t num_breakpoints = breakpoints.GetSize();
 
@@ -1479,7 +1487,7 @@ class CommandObjectBreakpointDelete : public 
CommandObjectParsed {
   return false;
 }
 
-if (command.empty()) {
+if (command.empty() && !m_options.m_delete_disabled) {
   if (!m_options.m_force &&
   !m_interpreter.Confirm(
   "About to delete all breakpoints, do you want to do that?",
@@ -1495,10 +1503,34 @@ class CommandObjectBreakpointDelete : public 
CommandObjectParsed {
 } else {
   // Particular breakpoint selected; disable that breakpoint.
   BreakpointIDList valid_bp_ids;
-  CommandObjectMultiwordBreakpoint::VerifyBreakpointOrLocationIDs(
-  command, &target, result, &valid_bp_ids,
-  BreakpointName::Permissions::PermissionKinds::deletePerm);
+  
+  if (m_options.m_delete_disabled) {
+BreakpointIDList excluded_bp_ids;
 
+if (!command.empty()) {
+  CommandObjectMultiwordBreakpoint::VerifyBreakpointOrLocationIDs(
+  command, &target, result, &excluded_bp_ids,
+  BreakpointName::Permissions::PermissionKinds::deletePerm);
+}
+for (auto breakpoint_sp : breakpoints.Breakpoints()) {
+  if (!breakpoint_sp->IsEnabled() && breakpoint_sp->AllowDelete()) {
+BreakpointID bp_id(breakpoint_sp->GetID());
+size_t pos = 0;
+if (!excluded_bp_ids.FindBreakpointID(bp_id, &pos))
+  valid_bp_ids.AddBreakpointID(breakpoint_sp->GetID());
+  }
+}
+if (valid_bp_ids.GetSize() == 0) {
+  result.AppendError("No disabled breakpoints.");
+  result.SetStatus(eReturnStatusFailed);
+  return false;
+}
+  } else {
+CommandObjectMultiwordBreakpoint::VerifyBreakpointOrLocationIDs(
+command, &target, result, &valid_bp_ids,
+BreakpointName::Permissions::PermissionKinds::deletePerm);
+  }
+  
   if (result.Succeeded()) {
 int delete_count = 0;
 int disable_count = 0;

diff  --git a/lldb/source/Commands/Options.td b/lldb/source/Commands/Options.td
index f2401dc5f326..8c83fd20a366 100644
--- a/lldb/source/Commands/Options.td
+++ b/lldb/source/Commands/Options.td
@@ -227,6 +227,9 @@ let Command = "breakpoint delete" in {
   def breakpoint_delete_dummy_breakpoints : Option<"dummy-

[Lldb-commits] [lldb] 94b0d83 - Fix reporting the lack of global variables in "target var".

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-09-21T17:29:40-07:00
New Revision: 94b0d836a105116220052313df5a58473f706cdf

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

LOG: Fix reporting the lack of global variables in "target var".

There was a little thinko which meant when stopped in a frame with
debug information but whose CU didn't have any global variables we
report:

no debug info for frame 

This patch fixes that error message to say the intended:

no global variables in current compile unit



Added: 
lldb/test/API/functionalities/target_var/no_vars/Makefile
lldb/test/API/functionalities/target_var/no_vars/TestTargetVarNoVars.py
lldb/test/API/functionalities/target_var/no_vars/main.c

Modified: 
lldb/source/Commands/CommandObjectTarget.cpp

Removed: 




diff  --git a/lldb/source/Commands/CommandObjectTarget.cpp 
b/lldb/source/Commands/CommandObjectTarget.cpp
index 30fdaf9ec9a2..431c2f3a19f0 100644
--- a/lldb/source/Commands/CommandObjectTarget.cpp
+++ b/lldb/source/Commands/CommandObjectTarget.cpp
@@ -907,6 +907,7 @@ class CommandObjectTargetVariable : public 
CommandObjectParsed {
 CompileUnit *comp_unit = nullptr;
 if (frame) {
   SymbolContext sc = frame->GetSymbolContext(eSymbolContextCompUnit);
+  comp_unit = sc.comp_unit;
   if (sc.comp_unit) {
 const bool can_create = true;
 VariableListSP comp_unit_varlist_sp(

diff  --git a/lldb/test/API/functionalities/target_var/no_vars/Makefile 
b/lldb/test/API/functionalities/target_var/no_vars/Makefile
new file mode 100644
index ..10495940055b
--- /dev/null
+++ b/lldb/test/API/functionalities/target_var/no_vars/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules

diff  --git 
a/lldb/test/API/functionalities/target_var/no_vars/TestTargetVarNoVars.py 
b/lldb/test/API/functionalities/target_var/no_vars/TestTargetVarNoVars.py
new file mode 100644
index ..60ca8b1252b3
--- /dev/null
+++ b/lldb/test/API/functionalities/target_var/no_vars/TestTargetVarNoVars.py
@@ -0,0 +1,21 @@
+"""
+Test that target var with no variables returns a correct error
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestTargetVarNoVars(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+NO_DEBUG_INFO_TESTCASE = True
+
+def test_target_var_no_vars(self):
+self.build()
+lldbutil.run_to_name_breakpoint(self, 'main')
+self.expect("target variable", substrs=['no global variables in 
current compile unit', 'main.c'], error=True)
+

diff  --git a/lldb/test/API/functionalities/target_var/no_vars/main.c 
b/lldb/test/API/functionalities/target_var/no_vars/main.c
new file mode 100644
index ..d7877b0a519b
--- /dev/null
+++ b/lldb/test/API/functionalities/target_var/no_vars/main.c
@@ -0,0 +1,5 @@
+int
+main(int argc, char **argv)
+{
+  return argc;
+}



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

[Lldb-commits] [lldb] f723d19 - Add '<' meta command to read in code from external file

[Jim Ingham via lldb-commits]

Author: Patrick Beard
Date: 2020-09-16T11:36:54-07:00
New Revision: f723d193e2c92ea6903e3debfee32b13354808bc

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

LOG: Add '<' meta command to read in code from external file

Perform all error handling in ReadCode()

Add :help text describing “< path”, add extra line before Commands

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

Added: 


Modified: 
lldb/source/Expression/REPL.cpp

Removed: 




diff  --git a/lldb/source/Expression/REPL.cpp b/lldb/source/Expression/REPL.cpp
index fd7c39686921..1f2b009c4893 100644
--- a/lldb/source/Expression/REPL.cpp
+++ b/lldb/source/Expression/REPL.cpp
@@ -123,10 +123,11 @@ const char *REPL::IOHandlerGetHelpPrologue() {
  "Valid statements, expressions, and declarations are immediately "
  "compiled and executed.\n\n"
  "The complete set of LLDB debugging commands are also available as "
- "described below.  Commands "
+ "described below.\n\nCommands "
  "must be prefixed with a colon at the REPL prompt (:quit for "
  "example.)  Typing just a colon "
- "followed by return will switch to the LLDB prompt.\n\n";
+ "followed by return will switch to the LLDB prompt.\n\n"
+ "Type “< path” to read in code from a text file “path”.\n\n";
 }
 
 bool REPL::IOHandlerIsInputComplete(IOHandler &io_handler, StringList &lines) {
@@ -179,6 +180,36 @@ int REPL::IOHandlerFixIndentation(IOHandler &io_handler,
   return (int)desired_indent - actual_indent;
 }
 
+static bool ReadCode(const std::string &path, std::string &code,
+ lldb::StreamFileSP &error_sp) {
+  auto &fs = FileSystem::Instance();
+  llvm::Twine pathTwine(path);
+  if (!fs.Exists(pathTwine)) {
+error_sp->Printf("no such file at path '%s'\n", path.c_str());
+return false;
+  }
+  if (!fs.Readable(pathTwine)) {
+error_sp->Printf("could not read file at path '%s'\n", path.c_str());
+return false;
+  }
+  const size_t file_size = fs.GetByteSize(pathTwine);
+  const size_t max_size = code.max_size();
+  if (file_size > max_size) {
+error_sp->Printf("file at path '%s' too large: "
+ "file_size = %llu, max_size = %llu\n",
+ path.c_str(), file_size, max_size);
+return false;
+  }
+  auto data_sp = fs.CreateDataBuffer(pathTwine);
+  if (data_sp == nullptr) {
+error_sp->Printf("could not create buffer for file at path '%s'\n",
+ path.c_str());
+return false;
+  }
+  code.assign((const char *)data_sp->GetBytes(), data_sp->GetByteSize());
+  return true;
+}
+
 void REPL::IOHandlerInputComplete(IOHandler &io_handler, std::string &code) {
   lldb::StreamFileSP output_sp(io_handler.GetOutputStreamFileSP());
   lldb::StreamFileSP error_sp(io_handler.GetErrorStreamFileSP());
@@ -257,6 +288,15 @@ void REPL::IOHandlerInputComplete(IOHandler &io_handler, 
std::string &code) {
 }
   }
 } else {
+  if (code[0] == '<') {
+// User wants to read code from a file.
+// Interpret rest of line as a literal path.
+auto path = llvm::StringRef(code.substr(1)).trim().str();
+if (!ReadCode(path, code, error_sp)) {
+  return;
+}
+  }
+
   // Unwind any expression we might have been running in case our REPL
   // expression crashed and the user was looking around
   if (m_dedicated_repl_mode) {



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

[Lldb-commits] [lldb] b6db0a5 - Add python enumerators for SBTypeEnumMemberList, and some tests for this API.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-08-14T09:57:46-07:00
New Revision: b6db0a544df1f28e7fa53b74e19839e55e63c8c9

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

LOG: Add python enumerators for SBTypeEnumMemberList, and some tests for this 
API.

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

Added: 


Modified: 
lldb/bindings/interface/SBTypeEnumMember.i
lldb/test/API/lang/c/enum_types/TestEnumTypes.py
lldb/test/API/lang/c/enum_types/main.c

Removed: 




diff  --git a/lldb/bindings/interface/SBTypeEnumMember.i 
b/lldb/bindings/interface/SBTypeEnumMember.i
index 006bdeaa8cee..518e2bf90115 100644
--- a/lldb/bindings/interface/SBTypeEnumMember.i
+++ b/lldb/bindings/interface/SBTypeEnumMember.i
@@ -71,10 +71,18 @@ protected:
 SBTypeEnumMember (const lldb::TypeEnumMemberImplSP &);
 };
 
-%feature(
-"docstring",
-"Represents a list of SBTypeEnumMembers."
-) SBTypeEnumMemberList;
+%feature("docstring",
+"Represents a list of SBTypeEnumMembers.
+SBTypeEnumMemberList supports SBTypeEnumMember iteration.
+It also supports [] access either by index, or by enum
+element name by doing:
+
+  myType = target.FindFirstType('MyEnumWithElementA')
+  members = myType.GetEnumMembers()
+  first_elem = members[0]
+  elem_A = members['A']
+
+") SBTypeEnumMemberList;
 
 class SBTypeEnumMemberList
 {
@@ -99,6 +107,29 @@ public:
 uint32_t
 GetSize();
 
+#ifdef SWIGPYTHON
+%pythoncode %{
+def __iter__(self):
+'''Iterate over all members in a lldb.SBTypeEnumMemberList 
object.'''
+return lldb_iter(self, 'GetSize', 'GetTypeEnumMemberAtIndex')
+
+def __len__(self):
+'''Return the number of members in a lldb.SBTypeEnumMemberList 
object.'''
+return self.GetSize()
+
+def __getitem__(self, key):
+  num_elements = self.GetSize()
+  if type(key) is int:
+  if key < num_elements:
+  return self.GetTypeEnumMemberAtIndex(key)
+  elif type(key) is str:
+  for idx in range(num_elements):
+  item = self.GetTypeEnumMemberAtIndex(idx)
+  if item.name == key:
+  return item
+  return None
+%} 
+#endif
 
 private:
 std::unique_ptr m_opaque_ap;

diff  --git a/lldb/test/API/lang/c/enum_types/TestEnumTypes.py 
b/lldb/test/API/lang/c/enum_types/TestEnumTypes.py
index cb5bb8eccaa2..0442dd34196a 100644
--- a/lldb/test/API/lang/c/enum_types/TestEnumTypes.py
+++ b/lldb/test/API/lang/c/enum_types/TestEnumTypes.py
@@ -18,11 +18,9 @@ def setUp(self):
 # Find the line number to break inside main().
 self.line = line_number('main.c', '// Set break point at this line.')
 
-def test(self):
-"""Test 'image lookup -t days' and check for correct display and enum 
value printing."""
+def test_command_line(self):
+"""Test 'image lookup -t enum_test_days' and check for correct display 
and enum value printing."""
 self.build()
-exe = self.getBuildArtifact("a.out")
-self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
 
 lldbutil.run_to_source_breakpoint(
 self, '// Breakpoint for bitfield', lldb.SBFileSpec("main.c"))
@@ -63,10 +61,10 @@ def test(self):
 self.expect("breakpoint list -f", BREAKPOINT_HIT_ONCE,
 substrs=[' resolved, hit count = 1'])
 
-# Look up information about the 'days' enum type.
+# Look up information about the 'enum_test_days' enum type.
 # Check for correct display.
-self.expect("image lookup -t days", DATA_TYPES_DISPLAYED_CORRECTLY,
-substrs=['enum days {',
+self.expect("image lookup -t enum_test_days", 
DATA_TYPES_DISPLAYED_CORRECTLY,
+substrs=['enum enum_test_days {',
  'Monday',
  'Tuesday',
  'Wednesday',
@@ -124,3 +122,41 @@ def test(self):
 'check for valid enumeration value',
 substrs=[enum_value])
 lldbutil.continue_to_breakpoint(self.process(), bkpt)
+
+def check_enum_members(self, members):
+name_matches = ["Monday", "Tuesday", "Wednesday", "Thursday", 
"Friday", "Saturday", "Sunday", "kNumDays"]
+value_matches = [-3, -2, -1, 0, 1, 2, 3, 4]
+
+# First test that the list of members from the type works
+num_matches = len(name_matches)
+self.assertEqual(len(members), num_matches, "enum_members returns the 
right number of elements")
+for idx in range(0, num_matches):
+member = members[idx]
+self.assertTrue(member.IsValid(), "Got a valid member for idx: 
%d"%(idx))
+se

[Lldb-commits] [lldb] d3dfd8c - Add a setting to force stepping to always run all threads.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-08-07T14:47:31-07:00
New Revision: d3dfd8cec44072302818c34193d898903dbaef8f

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

LOG: Add a setting to force stepping to always run all threads.
Also allow ScriptedThreadPlans to set & get their StopOthers
state.



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

Added: 


Modified: 
lldb/bindings/interface/SBThreadPlan.i
lldb/include/lldb/API/SBThreadPlan.h
lldb/include/lldb/Target/Process.h
lldb/include/lldb/Target/ThreadPlanPython.h
lldb/source/API/SBThreadPlan.cpp
lldb/source/Commands/CommandObjectThread.cpp
lldb/source/Target/Process.cpp
lldb/source/Target/TargetProperties.td
lldb/source/Target/Thread.cpp
lldb/source/Target/ThreadPlanPython.cpp
lldb/test/API/functionalities/step_scripted/Steps.py
lldb/test/API/functionalities/step_scripted/TestStepScripted.py

Removed: 




diff  --git a/lldb/bindings/interface/SBThreadPlan.i 
b/lldb/bindings/interface/SBThreadPlan.i
index 36131d529b7b..2003c6fdee3a 100644
--- a/lldb/bindings/interface/SBThreadPlan.i
+++ b/lldb/bindings/interface/SBThreadPlan.i
@@ -92,6 +92,14 @@ public:
 bool
 IsPlanStale();
 
+%feature("docstring", "Return whether this plan will ask to stop other 
threads when it runs.") GetStopOthers;
+bool
+GetStopOthers();
+  
+%feature("docstring", "Set whether this plan will ask to stop other 
threads when it runs.")GetStopOthers;
+void
+SetStopOthers(bool stop_others);
+
 SBThreadPlan
 QueueThreadPlanForStepOverRange (SBAddress &start_address,
  lldb::addr_t range_size);

diff  --git a/lldb/include/lldb/API/SBThreadPlan.h 
b/lldb/include/lldb/API/SBThreadPlan.h
index 6639c10e437b..0dc48437a668 100644
--- a/lldb/include/lldb/API/SBThreadPlan.h
+++ b/lldb/include/lldb/API/SBThreadPlan.h
@@ -77,6 +77,10 @@ class LLDB_API SBThreadPlan {
 
   bool IsValid();
 
+  bool GetStopOthers();
+
+  void SetStopOthers(bool stop_others);
+
   // This section allows an SBThreadPlan to push another of the common types of
   // plans...
   SBThreadPlan QueueThreadPlanForStepOverRange(SBAddress &start_address,

diff  --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index bf9b64547ed5..2abedb8f6e2e 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -91,6 +91,7 @@ class ProcessProperties : public Properties {
   std::chrono::seconds GetUtilityExpressionTimeout() const;
   bool GetOSPluginReportsAllThreads() const;
   void SetOSPluginReportsAllThreads(bool does_report);
+  bool GetSteppingRunsAllThreads() const;
 
 protected:
   Process *m_process; // Can be nullptr for global ProcessProperties

diff  --git a/lldb/include/lldb/Target/ThreadPlanPython.h 
b/lldb/include/lldb/Target/ThreadPlanPython.h
index 27bf3a560b1f..c04500ad5de8 100644
--- a/lldb/include/lldb/Target/ThreadPlanPython.h
+++ b/lldb/include/lldb/Target/ThreadPlanPython.h
@@ -45,7 +45,9 @@ class ThreadPlanPython : public ThreadPlan {
 
   bool WillStop() override;
 
-  bool StopOthers() override;
+  bool StopOthers() override { return m_stop_others; }
+
+  void SetStopOthers(bool new_value) { m_stop_others = new_value; }
 
   void DidPush() override;
 
@@ -67,6 +69,7 @@ class ThreadPlanPython : public ThreadPlan {
   std::string m_error_str;
   StructuredData::ObjectSP m_implementation_sp;
   bool m_did_push;
+  bool m_stop_others;
 
   ThreadPlanPython(const ThreadPlanPython &) = delete;
   const ThreadPlanPython &operator=(const ThreadPlanPython &) = delete;

diff  --git a/lldb/source/API/SBThreadPlan.cpp 
b/lldb/source/API/SBThreadPlan.cpp
index c740c8b7492f..9af673b0f3a9 100644
--- a/lldb/source/API/SBThreadPlan.cpp
+++ b/lldb/source/API/SBThreadPlan.cpp
@@ -196,6 +196,23 @@ bool SBThreadPlan::IsValid() {
   return false;
 }
 
+bool SBThreadPlan::GetStopOthers() {
+  LLDB_RECORD_METHOD_NO_ARGS(bool, SBThreadPlan, GetStopOthers);
+
+  ThreadPlanSP thread_plan_sp(GetSP());
+  if (thread_plan_sp)
+return thread_plan_sp->StopOthers();
+  return false;
+}
+
+void SBThreadPlan::SetStopOthers(bool stop_others) {
+  LLDB_RECORD_METHOD(void, SBThreadPlan, SetStopOthers, (bool), stop_others);
+
+  ThreadPlanSP thread_plan_sp(GetSP());
+  if (thread_plan_sp)
+thread_plan_sp->SetStopOthers(stop_others);
+}
+
 // This section allows an SBThreadPlan to push another of the common types of
 // plans...
 //
@@ -463,6 +480,8 @@ void RegisterMethods(Registry &R) {
   LLDB_REGISTER_METHOD(bool, SBThreadPlan, IsPlanComplete, ());
   LLDB_REGISTER_METHOD(bool, SBThreadPlan, IsPlanStale, ());
   LLDB_REGISTER_METHOD(bool, SBThreadPlan, IsValid, ());
+  LLDB_REGISTER_METHOD(void, SBThreadPlan, SetStopOthers

[Lldb-commits] [lldb] 1c1ffa6 - GetPath() returns a std::string temporary. You can't reference just the c_str.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-08-05T19:12:15-07:00
New Revision: 1c1ffa6a300a60c81be41a3e08a4e9da7499adc1

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

LOG: GetPath() returns a std::string temporary.  You can't reference just the 
c_str.

Found by the static analyzer.

Added: 


Modified: 
lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp

Removed: 




diff  --git a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp 
b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
index 338c798e6cef..383cc5b59a37 100644
--- a/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
+++ b/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
@@ -1887,15 +1887,15 @@ class MachSymtabSectionInfo {
   m_section_infos[n_sect].vm_range.SetByteSize(
   section_sp->GetByteSize());
 } else {
-  const char *filename = "";
+  std::string filename = "";
   SectionSP first_section_sp(m_section_list->GetSectionAtIndex(0));
   if (first_section_sp)
-filename = 
first_section_sp->GetObjectFile()->GetFileSpec().GetPath().c_str();
+filename = 
first_section_sp->GetObjectFile()->GetFileSpec().GetPath();
 
   Host::SystemLog(Host::eSystemLogError,
   "error: unable to find section %d for a symbol in 
%s, corrupt file?\n",
   n_sect, 
-  filename);
+  filename.c_str());
 }
   }
   if (m_section_infos[n_sect].vm_range.Contains(file_addr)) {



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

[Lldb-commits] [lldb] 08063f8 - "|" used when "||" was meant in SBTarget::FindFunctions

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-08-05T19:02:00-07:00
New Revision: 08063f85a7eadb1e54d0a03e0307bf15319513e8

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

LOG: "|" used when "||" was meant in SBTarget::FindFunctions

Added: 


Modified: 
lldb/source/API/SBTarget.cpp
lldb/test/API/python_api/target/TestTargetAPI.py

Removed: 




diff  --git a/lldb/source/API/SBTarget.cpp b/lldb/source/API/SBTarget.cpp
index 04540a2fab43..34cab6217565 100644
--- a/lldb/source/API/SBTarget.cpp
+++ b/lldb/source/API/SBTarget.cpp
@@ -1791,7 +1791,7 @@ lldb::SBSymbolContextList SBTarget::FindFunctions(const 
char *name,
  (const char *, uint32_t), name, name_type_mask);
 
   lldb::SBSymbolContextList sb_sc_list;
-  if (!name | !name[0])
+  if (!name || !name[0])
 return LLDB_RECORD_RESULT(sb_sc_list);
 
   TargetSP target_sp(GetSP());

diff  --git a/lldb/test/API/python_api/target/TestTargetAPI.py 
b/lldb/test/API/python_api/target/TestTargetAPI.py
index 5bdbf90b3575..7db53883eb6a 100644
--- a/lldb/test/API/python_api/target/TestTargetAPI.py
+++ b/lldb/test/API/python_api/target/TestTargetAPI.py
@@ -283,6 +283,10 @@ def find_functions(self, exe_name):
 target = self.dbg.CreateTarget(exe)
 self.assertTrue(target, VALID_TARGET)
 
+# Try it with a null name:
+list = target.FindFunctions(None, lldb.eFunctionNameTypeAuto)
+self.assertTrue(list.GetSize() == 0)
+
 list = target.FindFunctions('c', lldb.eFunctionNameTypeAuto)
 self.assertTrue(list.GetSize() == 1)
 



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

[Lldb-commits] [lldb] 8d6aa68 - Remove the "bool" return from OptionValue::Clear and its subclasses.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-07-21T11:32:55-07:00
New Revision: 8d6aa688eeffea4b9151d1a208ed619ca50c823a

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

LOG: Remove the "bool" return from OptionValue::Clear and its subclasses.

Every override returns true and its return value is never checked.  I can't
see how clearing an OptionValue could fail, or what you would
do if it did.  The return serves no purpose.

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

Added: 


Modified: 
lldb/include/lldb/Interpreter/OptionValue.h
lldb/include/lldb/Interpreter/OptionValueArch.h
lldb/include/lldb/Interpreter/OptionValueArray.h
lldb/include/lldb/Interpreter/OptionValueBoolean.h
lldb/include/lldb/Interpreter/OptionValueChar.h
lldb/include/lldb/Interpreter/OptionValueDictionary.h
lldb/include/lldb/Interpreter/OptionValueEnumeration.h
lldb/include/lldb/Interpreter/OptionValueFileColonLine.h
lldb/include/lldb/Interpreter/OptionValueFileSpec.h
lldb/include/lldb/Interpreter/OptionValueFileSpecList.h
lldb/include/lldb/Interpreter/OptionValueFormat.h
lldb/include/lldb/Interpreter/OptionValueFormatEntity.h
lldb/include/lldb/Interpreter/OptionValueLanguage.h
lldb/include/lldb/Interpreter/OptionValuePathMappings.h
lldb/include/lldb/Interpreter/OptionValueProperties.h
lldb/include/lldb/Interpreter/OptionValueRegex.h
lldb/include/lldb/Interpreter/OptionValueSInt64.h
lldb/include/lldb/Interpreter/OptionValueString.h
lldb/include/lldb/Interpreter/OptionValueUInt64.h
lldb/include/lldb/Interpreter/OptionValueUUID.h
lldb/source/Interpreter/OptionValueFormatEntity.cpp
lldb/source/Interpreter/OptionValueProperties.cpp

Removed: 




diff  --git a/lldb/include/lldb/Interpreter/OptionValue.h 
b/lldb/include/lldb/Interpreter/OptionValue.h
index 27a5ddea116b..a8176e39940a 100644
--- a/lldb/include/lldb/Interpreter/OptionValue.h
+++ b/lldb/include/lldb/Interpreter/OptionValue.h
@@ -85,7 +85,7 @@ class OptionValue {
   SetValueFromString(llvm::StringRef value,
  VarSetOperationType op = eVarSetOperationAssign);
 
-  virtual bool Clear() = 0;
+  virtual void Clear() = 0;
 
   virtual lldb::OptionValueSP DeepCopy() const = 0;
 

diff  --git a/lldb/include/lldb/Interpreter/OptionValueArch.h 
b/lldb/include/lldb/Interpreter/OptionValueArch.h
index 7b63c68fddbf..809261ef22c3 100644
--- a/lldb/include/lldb/Interpreter/OptionValueArch.h
+++ b/lldb/include/lldb/Interpreter/OptionValueArch.h
@@ -47,10 +47,9 @@ class OptionValueArch : public OptionValue {
   SetValueFromString(const char *,
  VarSetOperationType = eVarSetOperationAssign) = delete;
 
-  bool Clear() override {
+  void Clear() override {
 m_current_value = m_default_value;
 m_value_was_set = false;
-return true;
   }
 
   lldb::OptionValueSP DeepCopy() const override;

diff  --git a/lldb/include/lldb/Interpreter/OptionValueArray.h 
b/lldb/include/lldb/Interpreter/OptionValueArray.h
index 000351c2f586..4546bbb80394 100644
--- a/lldb/include/lldb/Interpreter/OptionValueArray.h
+++ b/lldb/include/lldb/Interpreter/OptionValueArray.h
@@ -36,10 +36,9 @@ class OptionValueArray : public OptionValue {
   SetValueFromString(const char *,
  VarSetOperationType = eVarSetOperationAssign) = delete;
 
-  bool Clear() override {
+  void Clear() override {
 m_values.clear();
 m_value_was_set = false;
-return true;
   }
 
   lldb::OptionValueSP DeepCopy() const override;

diff  --git a/lldb/include/lldb/Interpreter/OptionValueBoolean.h 
b/lldb/include/lldb/Interpreter/OptionValueBoolean.h
index d221f6d034c2..1af14a4980ed 100644
--- a/lldb/include/lldb/Interpreter/OptionValueBoolean.h
+++ b/lldb/include/lldb/Interpreter/OptionValueBoolean.h
@@ -37,10 +37,9 @@ class OptionValueBoolean : public OptionValue {
   SetValueFromString(const char *,
  VarSetOperationType = eVarSetOperationAssign) = delete;
 
-  bool Clear() override {
+  void Clear() override {
 m_current_value = m_default_value;
 m_value_was_set = false;
-return true;
   }
 
   void AutoComplete(CommandInterpreter &interpreter,

diff  --git a/lldb/include/lldb/Interpreter/OptionValueChar.h 
b/lldb/include/lldb/Interpreter/OptionValueChar.h
index 8d0aa91d7076..a8ecf507a4cf 100644
--- a/lldb/include/lldb/Interpreter/OptionValueChar.h
+++ b/lldb/include/lldb/Interpreter/OptionValueChar.h
@@ -38,10 +38,9 @@ class OptionValueChar : public OptionValue {
   SetValueFromString(const char *,
  VarSetOperationType = eVarSetOperationAssign) = delete;
 
-  bool Clear() override {
+  void Clear() override {
 m_current_value = m_default_value;
 m_value_was_set = false;
-return true;
   }
 
   // 

[Lldb-commits] [lldb] bc0a9a1 - Add an option (-y) to "break set" and "source list" that uses the same

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-07-20T17:40:36-07:00
New Revision: bc0a9a17a4a658153f4b524da3274d33a98d1c5b

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

LOG: Add an option (-y) to "break set" and "source list" that uses the same
file:line:column form that we use to print out locations.  Since we
print them this way it makes sense we also accept that form.

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

Added: 
lldb/include/lldb/Interpreter/OptionValueFileColonLine.h
lldb/source/Interpreter/OptionValueFileColonLine.cpp

lldb/test/API/functionalities/breakpoint/breakpoint_by_file_colon_line/Makefile

lldb/test/API/functionalities/breakpoint/breakpoint_by_file_colon_line/TestBreakpointByFileColonLine.py

lldb/test/API/functionalities/breakpoint/breakpoint_by_file_colon_line/main.c
lldb/unittests/Interpreter/TestOptionValueFileColonLine.cpp

Modified: 
lldb/include/lldb/Interpreter/OptionValue.h
lldb/include/lldb/Interpreter/OptionValues.h
lldb/include/lldb/lldb-defines.h
lldb/include/lldb/lldb-enumerations.h
lldb/packages/Python/lldbsuite/test/lldbutil.py
lldb/source/Commands/CommandObjectBreakpoint.cpp
lldb/source/Commands/CommandObjectSource.cpp
lldb/source/Commands/Options.td
lldb/source/Interpreter/CMakeLists.txt
lldb/source/Interpreter/CommandObject.cpp
lldb/source/Interpreter/OptionValue.cpp
lldb/source/Interpreter/OptionValueArray.cpp
lldb/source/Interpreter/OptionValueDictionary.cpp
lldb/source/Interpreter/OptionValueFileSpec.cpp
lldb/source/Interpreter/Property.cpp
lldb/test/API/source-manager/TestSourceManager.py
lldb/unittests/Interpreter/CMakeLists.txt

Removed: 




diff  --git a/lldb/include/lldb/Interpreter/OptionValue.h 
b/lldb/include/lldb/Interpreter/OptionValue.h
index 5b07427094bf..27a5ddea116b 100644
--- a/lldb/include/lldb/Interpreter/OptionValue.h
+++ b/lldb/include/lldb/Interpreter/OptionValue.h
@@ -31,6 +31,7 @@ class OptionValue {
 eTypeChar,
 eTypeDictionary,
 eTypeEnum,
+eTypeFileLineColumn,
 eTypeFileSpec,
 eTypeFileSpecList,
 eTypeFormat,
@@ -135,6 +136,8 @@ class OptionValue {
   return eTypeDictionary;
 case 1u << eTypeEnum:
   return eTypeEnum;
+case 1u << eTypeFileLineColumn:
+  return eTypeFileLineColumn;
 case 1u << eTypeFileSpec:
   return eTypeFileSpec;
 case 1u << eTypeFileSpecList:

diff  --git a/lldb/include/lldb/Interpreter/OptionValueFileColonLine.h 
b/lldb/include/lldb/Interpreter/OptionValueFileColonLine.h
new file mode 100644
index ..6285c03afa14
--- /dev/null
+++ b/lldb/include/lldb/Interpreter/OptionValueFileColonLine.h
@@ -0,0 +1,64 @@
+//===-- OptionValueFileColonLine.h ---*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLDB_INTERPRETER_OPTIONVALUEFILECOLONLINE_H
+#define LLDB_INTERPRETER_OPTIONVALUEFILECOLONLINE_H
+
+#include "lldb/Interpreter/OptionValue.h"
+
+#include "lldb/Utility/FileSpec.h"
+#include "llvm/Support/Chrono.h"
+
+namespace lldb_private {
+
+class OptionValueFileColonLine : public OptionValue {
+public:
+  OptionValueFileColonLine();
+  OptionValueFileColonLine(const llvm::StringRef input);
+
+  ~OptionValueFileColonLine() override {}
+
+  OptionValue::Type GetType() const override { return eTypeFileLineColumn; }
+
+  void DumpValue(const ExecutionContext *exe_ctx, Stream &strm,
+ uint32_t dump_mask) override;
+
+  Status
+  SetValueFromString(llvm::StringRef value,
+ VarSetOperationType op = eVarSetOperationAssign) override;
+  Status
+  SetValueFromString(const char *,
+ VarSetOperationType = eVarSetOperationAssign) = delete;
+
+  bool Clear() override {
+m_file_spec.Clear();
+m_line_number = LLDB_INVALID_LINE_NUMBER;
+m_column_number = 0;
+  }
+
+  lldb::OptionValueSP DeepCopy() const override;
+
+  void AutoComplete(CommandInterpreter &interpreter,
+CompletionRequest &request) override;
+
+  FileSpec &GetFileSpec() { return m_file_spec; }
+  uint32_t GetLineNumber() { return m_line_number; }
+  uint32_t GetColumnNumber() { return m_column_number; }
+  
+  void SetCompletionMask(uint32_t mask) { m_completion_mask = mask; }
+
+protected:
+  FileSpec m_file_spec;
+  uint32_t m_line_number;
+  uint32_t m_column_number;
+  uint32_t m_completion_mask;
+};
+
+} // namespace lldb_private
+
+#endif // LLDB_INTERPRETER_OPTIONVALUEFILECOLONLINE_H

diff  --git a/lldb/i

[Lldb-commits] [Differential] D83975: Add an option to "break set" and "source list" that takes a line spec in the form file:line:column

[Jim Ingham via lldb-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
jingham marked 2 inline comments as done.
Closed by commit rGbc0a9a17a4a6: Add an option (-y) to "break set" 
and "source list" that uses the same (authored by jingham).

Changed prior to commit:
  https://reviews.llvm.org/D83975?vs=278928&id=279035#toc

Repository:
  rG LLVM Github Monorepo

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


  https://reviews.llvm.org/D83975

Files:
  lldb/include/lldb/Interpreter/OptionValue.h
  lldb/include/lldb/Interpreter/OptionValueFileColonLine.h
  lldb/include/lldb/Interpreter/OptionValues.h
  lldb/include/lldb/lldb-defines.h
  lldb/include/lldb/lldb-enumerations.h
  lldb/packages/Python/lldbsuite/test/lldbutil.py
  lldb/source/Commands/CommandObjectBreakpoint.cpp
  lldb/source/Commands/CommandObjectSource.cpp
  lldb/source/Commands/Options.td
  lldb/source/Interpreter/CMakeLists.txt
  lldb/source/Interpreter/CommandObject.cpp
  lldb/source/Interpreter/OptionValue.cpp
  lldb/source/Interpreter/OptionValueArray.cpp
  lldb/source/Interpreter/OptionValueDictionary.cpp
  lldb/source/Interpreter/OptionValueFileColonLine.cpp
  lldb/source/Interpreter/OptionValueFileSpec.cpp
  lldb/source/Interpreter/Property.cpp
  
lldb/test/API/functionalities/breakpoint/breakpoint_by_file_colon_line/Makefile
  
lldb/test/API/functionalities/breakpoint/breakpoint_by_file_colon_line/TestBreakpointByFileColonLine.py
  lldb/test/API/functionalities/breakpoint/breakpoint_by_file_colon_line/main.c
  lldb/test/API/source-manager/TestSourceManager.py
  lldb/unittests/Interpreter/CMakeLists.txt
  lldb/unittests/Interpreter/TestOptionValueFileColonLine.cpp

Index: lldb/unittests/Interpreter/TestOptionValueFileColonLine.cpp
===
--- /dev/null
+++ lldb/unittests/Interpreter/TestOptionValueFileColonLine.cpp
@@ -0,0 +1,57 @@
+//===-- ArgsTest.cpp --===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/Interpreter/OptionValueFileColonLine.h"
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/Utility/Status.h"
+#include "gtest/gtest.h"
+
+using namespace lldb_private;
+
+void CheckSetting(const char *input, bool success, const char *path = nullptr,
+  uint32_t line_number = LLDB_INVALID_ADDRESS,
+  uint32_t column_number = 0) {
+
+  OptionValueFileColonLine value;
+  Status error;
+  llvm::StringRef s_ref(input);
+  error = value.SetValueFromString(s_ref);
+  ASSERT_EQ(error.Success(), success);
+
+  // If we were meant to fail, we don't need to do more checks:
+  if (!success)
+return;
+
+  ASSERT_EQ(value.GetLineNumber(), line_number);
+  ASSERT_EQ(value.GetColumnNumber(), column_number);
+  std::string value_path = value.GetFileSpec().GetPath();
+  ASSERT_STREQ(value_path.c_str(), path);
+}
+
+TEST(OptionValueFileColonLine, setFromString) {
+  OptionValueFileColonLine value;
+  Status error;
+
+  // Make sure a default constructed value is invalid:
+  ASSERT_EQ(value.GetLineNumber(), LLDB_INVALID_LINE_NUMBER);
+  ASSERT_EQ(value.GetColumnNumber(), 0);
+  ASSERT_FALSE(value.GetFileSpec());
+
+  // Make sure it is an error to pass a specifier with no line number:
+  CheckSetting("foo.c", false);
+
+  // Now try with just a file & line:
+  CheckSetting("foo.c:12", true, "foo.c", 12);
+  CheckSetting("foo.c:12:20", true, "foo.c", 12, 20);
+  // Make sure a colon doesn't mess us up:
+  CheckSetting("foo:bar.c:12", true, "foo:bar.c", 12);
+  CheckSetting("foo:bar.c:12:20", true, "foo:bar.c", 12, 20);
+  // Try errors in the line number:
+  CheckSetting("foo.c:12c", false);
+  CheckSetting("foo.c:12:20c", false);
+}
Index: lldb/unittests/Interpreter/CMakeLists.txt
===
--- lldb/unittests/Interpreter/CMakeLists.txt
+++ lldb/unittests/Interpreter/CMakeLists.txt
@@ -1,6 +1,7 @@
 add_lldb_unittest(InterpreterTests
   TestCompletion.cpp
   TestOptionArgParser.cpp
+  TestOptionValueFileColonLine.cpp
 
   LINK_LIBS
 lldbInterpreter
Index: lldb/test/API/source-manager/TestSourceManager.py
===
--- lldb/test/API/source-manager/TestSourceManager.py
+++ lldb/test/API/source-manager/TestSourceManager.py
@@ -197,6 +197,14 @@
 SOURCE_DISPLAYED_CORRECTLY,
 substrs=['Hello world'])
 
+# Do the same thing with a file & line spec:
+self.expect(
+"source list -y main-copy.c:%d" %
+self.line,
+

[Lldb-commits] [lldb] e337350 - This is a refinement on 96601ec28b7efe5abf3479a1aa91bcedb235bbbd. The intent of that change was to do the same work for the computation of the locations of the children

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-07-10T11:11:59-07:00
New Revision: e337350be9d6efd72027c331f95ef33df61fdc43

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

LOG: This is a refinement on 96601ec28b7efe5abf3479a1aa91bcedb235bbbd. The 
intent of that change was to do the same work for the computation of the 
locations of the children of ValueObjectVariable as was done for the root 
ValueObjectVariable. This original patch did that by moving the computation 
from ValueObjectVariable to ValueObject. That fixed the problem but caused a 
handful of swift-lldb testsuite failures and a crash or two.

The problem is that synthetic value objects can sometimes represent objects in 
target memory, and other times they might be made up wholly in lldb memory, 
with pointers from one synthetic object to another, and so the 
ValueObjectVariable computation was not appropriate.

This patch delegates the computation to the root of the ValueObject in 
question. That solves the problem for ValueObjectVariable while not messing up 
the computation for ValueObjectConstResult or ValueObjectSynthetic.

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

Added: 


Modified: 
lldb/include/lldb/Core/ValueObject.h
lldb/include/lldb/Core/ValueObjectVariable.h
lldb/source/Core/ValueObject.cpp
lldb/source/Core/ValueObjectVariable.cpp

Removed: 




diff  --git a/lldb/include/lldb/Core/ValueObject.h 
b/lldb/include/lldb/Core/ValueObject.h
index 7c8a01beea56..0080368fd996 100644
--- a/lldb/include/lldb/Core/ValueObject.h
+++ b/lldb/include/lldb/Core/ValueObject.h
@@ -963,9 +963,14 @@ class ValueObject : public UserID {
 
   void SetPreferredDisplayLanguageIfNeeded(lldb::LanguageType);
 
+protected:
+  virtual void DoUpdateChildrenAddressType(ValueObject &valobj) { return; };
+
 private:
   virtual CompilerType MaybeCalculateCompleteType();
-  void UpdateChildrenAddressType();
+  void UpdateChildrenAddressType() {
+GetRoot()->DoUpdateChildrenAddressType(*this);
+  }
 
   lldb::ValueObjectSP GetValueForExpressionPath_Impl(
   llvm::StringRef expression_cstr,

diff  --git a/lldb/include/lldb/Core/ValueObjectVariable.h 
b/lldb/include/lldb/Core/ValueObjectVariable.h
index a0417e5e7d85..b7e262574a14 100644
--- a/lldb/include/lldb/Core/ValueObjectVariable.h
+++ b/lldb/include/lldb/Core/ValueObjectVariable.h
@@ -67,6 +67,8 @@ class ValueObjectVariable : public ValueObject {
 
 protected:
   bool UpdateValue() override;
+  
+  void DoUpdateChildrenAddressType(ValueObject &valobj) override;
 
   CompilerType GetCompilerTypeImpl() override;
 

diff  --git a/lldb/source/Core/ValueObject.cpp 
b/lldb/source/Core/ValueObject.cpp
index f13ad63dfb61..3a775b07e5e1 100644
--- a/lldb/source/Core/ValueObject.cpp
+++ b/lldb/source/Core/ValueObject.cpp
@@ -140,58 +140,6 @@ ValueObject::ValueObject(ExecutionContextScope *exe_scope,
 // Destructor
 ValueObject::~ValueObject() {}
 
-void ValueObject::UpdateChildrenAddressType() {
-  Value::ValueType value_type = m_value.GetValueType();
-  ExecutionContext exe_ctx(GetExecutionContextRef());
-  Process *process = exe_ctx.GetProcessPtr();
-  const bool process_is_alive = process && process->IsAlive();
-  const uint32_t type_info = GetCompilerType().GetTypeInfo();
-  const bool is_pointer_or_ref =
-  (type_info & (lldb::eTypeIsPointer | lldb::eTypeIsReference)) != 0;
-
-  switch (value_type) {
-  case Value::eValueTypeFileAddress:
-// If this type is a pointer, then its children will be considered load
-// addresses if the pointer or reference is dereferenced, but only if
-// the process is alive.
-//
-// There could be global variables like in the following code:
-// struct LinkedListNode { Foo* foo; LinkedListNode* next; };
-// Foo g_foo1;
-// Foo g_foo2;
-// LinkedListNode g_second_node = { &g_foo2, NULL };
-// LinkedListNode g_first_node = { &g_foo1, &g_second_node };
-//
-// When we aren't running, we should be able to look at these variables
-// using the "target variable" command. Children of the "g_first_node"
-// always will be of the same address type as the parent. But children
-// of the "next" member of LinkedListNode will become load addresses if
-// we have a live process, or remain a file address if it was a file
-// address.
-if (process_is_alive && is_pointer_or_ref)
-  SetAddressTypeOfChildren(eAddressTypeLoad);
-else
-  SetAddressTypeOfChildren(eAddressTypeFile);
-break;
-  case Value::eValueTypeHostAddress:
-// Same as above for load addresses, except children of pointer or refs
-// are always load addresses. Host addresses are used to store freeze
-// dried variables. If this type is a struct, the entire struct
-// contents will be copied 

Re: [Lldb-commits] [PATCH] D82155: [WIP][lldb/interpreter] Add ability to save lldb session to a file

[Jim Ingham via lldb-commits]

I’m not sure 

> On Jun 25, 2020, at 5:08 AM, Pavel Labath  wrote:
> 
> On 24/06/2020 18:55, Jim Ingham wrote:
>> 
>>> On Jun 22, 2020, at 5:52 AM, Pavel Labath via Phabricator via lldb-commits 
>>>  wrote:
>>> 
>>> labath added a comment.
>>> 
>>> This seems like it could be useful in some circumstances, though for the 
>>> use cases I am imagining (bug reporting) it would be easier to just 
>>> copy-paste the terminal contents.
>>> 
>>> As for the implementation, if the intention is for this to eventually 
>>> capture all debugger output, then I am not sure if this is the right 
>>> design. I think it would be fine for python/lua interpreters as those are 
>>> invoked from the lldb command interpreter, but I have a feeling that 
>>> routing the output printed via `Debugger::PrintAsync` back to the command 
>>> interpreter would look pretty weird. It may make sense for the core logic 
>>> of this to live in the Debugger or the IOHandler(Stack) classes -- though I 
>>> am not exactly sure about that either as the Debugger and CommandIntepreter 
>>> classes are fairly tightly coupled. However, I think that would be 
>>> consistent with the long term goal of reimplementing the command 
>>> interpreter on top of the SB API (in which case the `Debugger` object 
>>> should not know anything about the command interpreter (but it would still 
>>> need to to "something" with the PrintAsync output).
>> This isn’t directly related to how much and how we should capture lldb 
>> session output, and maybe I’m misunderstanding your meaning, but I wasn’t 
>> expecting that moving the command interpreter to use SB API’s would mean the 
>> Debugger Object would know nothing about the Command interpreter.  It would 
>> know as much about the command interpreter as it does about the script 
>> interpreter, namely the Debugger holds these objects and is the one to hand 
>> them out.  For instance when the breakpoint has a bunch of commands in its 
>> command action, it would go to the debugger to evaluate those commands.  I 
>> think that’s the reasonable place from which to vend the command and script 
>> interpreters.  So it’s okay IMO for the Debugger to know a little bit about 
>> these entities.  It shouldn’t know anything about the command syntax, etc.  
>> But since it is still the vendor of these objects, it seems okay for it to 
>> have an affordance to be notified of command results.
>> 
> 
> Well, the way I was thinking about this the "Debugger" would not know
> anything about Command *or* script interpreters. It would just know how
> to "debug" -- offer a programming API without any sort of textual
> interaction with a human.
> 
> However, this may be just a naming issue. There obviously needs to be
> some object which ties all of these together the thing which "debugs"
> and the thing which interfaces this with the user -- and it's not
> unreasonable to call this thing "the Debugger".
> 
> Nevertheless I think having this separation between "core debugger
> functionality" and a "particular way of interacting with the user" can
> be very useful:
> - it can enable someone to write a fully gdb-compatible (or some other
> debugger emulation) CLI experience on top of the "debugger core". This
> CLI would not need anything from the lldb CLI, but it could make use of
> all the "core" functionality (targets, breakpoints, threads, etc.)
> - someone wanting to build a lean-and-mean debugger for some specialized
> task could just make use of the "core" debugger functionality without
> pulling in the entire CLI
> 
> I don't expect either of these things to happen in the near future (or
> at all), but I like that this design would enable that sort of thing.
> Additionally (and this is the reason why I said (lldb_private::)Debugger
> in my first comment) this organization would avoid some problematic
> circular dependencies: If lldb_private::Debugger knows about the
> "command interpreter" and the "command interpreter" uses the SB api,
> then which side of the SB boundary does the command interpreter lie? It
> can't be "inside" the API, because it needs to access it to drive the
> debugging. But it also cannot be "outside" of the SB API, because then
> lldb_private::Debugger could not know about it.
> 
> That's why I figured that lldb::SBDebugger could be the "one debugger to
> rule them all", and lldb_private::Debugger could be "demoted" to just
> the "core" debugging facilities.
> 
> But now we're getting way ahead of ourselves...


One of the things that is core functionality in the debugger is “when X 
happens, do Y”.  When I stop, do something, when I hit a breakpoint do 
something, when a new shared library is loaded (we don’t offer this affordance 
yet, but we should), etc…  Similarly the script interpreter side of lldb gets 
pretty involved in formatting data.  Both of these tasks require non-trivial 
managing.   I think it would be annoying for every debugger client to have to 
code that up themselves.  Some of that c

Re: [Lldb-commits] [PATCH] D82155: [WIP][lldb/interpreter] Add ability to save lldb session to a file

[Jim Ingham via lldb-commits]

> On Jun 22, 2020, at 5:52 AM, Pavel Labath via Phabricator via lldb-commits 
>  wrote:
> 
> labath added a comment.
> 
> This seems like it could be useful in some circumstances, though for the use 
> cases I am imagining (bug reporting) it would be easier to just copy-paste 
> the terminal contents.
> 
> As for the implementation, if the intention is for this to eventually capture 
> all debugger output, then I am not sure if this is the right design. I think 
> it would be fine for python/lua interpreters as those are invoked from the 
> lldb command interpreter, but I have a feeling that routing the output 
> printed via `Debugger::PrintAsync` back to the command interpreter would look 
> pretty weird. It may make sense for the core logic of this to live in the 
> Debugger or the IOHandler(Stack) classes -- though I am not exactly sure 
> about that either as the Debugger and CommandIntepreter classes are fairly 
> tightly coupled. However, I think that would be consistent with the long term 
> goal of reimplementing the command interpreter on top of the SB API (in which 
> case the `Debugger` object should not know anything about the command 
> interpreter (but it would still need to to "something" with the PrintAsync 
> output).

This isn’t directly related to how much and how we should capture lldb session 
output, and maybe I’m misunderstanding your meaning, but I wasn’t expecting 
that moving the command interpreter to use SB API’s would mean the Debugger 
Object would know nothing about the Command interpreter.  It would know as much 
about the command interpreter as it does about the script interpreter, namely 
the Debugger holds these objects and is the one to hand them out.  For instance 
when the breakpoint has a bunch of commands in its command action, it would go 
to the debugger to evaluate those commands.  I think that’s the reasonable 
place from which to vend the command and script interpreters.  So it’s okay IMO 
for the Debugger to know a little bit about these entities.  It shouldn’t know 
anything about the command syntax, etc.  But since it is still the vendor of 
these objects, it seems okay for it to have an affordance to be notified of 
command results.

> 
> The test plan sounds fairly straight forward -- run lldb, execute a bunch of 
> commands, and finish it off with "session save". Then, verify that the file 
> has the "right" contents (e.g. with FileCheck). Besides multiline commands, 
> commands which do recursive processing are also interesting to exercise -- 
> e.g. "command source" or breakpoint callbacks. You also should decide what do 
> you want to happen with commands that are executed through the SB interface 
> (SBCommandInterpreter::HandleCommand) -- those will not normally go to the 
> debugger output, but I believe they will still be captured in the current 
> design...
> 
> 

Yes, I think we should be careful about this.  First off, I think command 
transcripts are not useful if you can’t link output to the command that 
triggered it.  And if we execute a command for instance in a data formatter, 
having that command output show up with no context in the log wouldn’t I think 
be helpful.  I think it would be useful to have a notion of user-actuated 
commands, and try to record those.  And it would also be good to provide some 
context.  For instance, if you have commands in a breakpoint action it would be 
great if you the output would identify them as such.

Jim


> 
> 
> Comment at: lldb/source/Interpreter/CommandInterpreter.cpp:2815
> 
> +  if (line.find("session save") == line.npos) {
> +*m_session_transcripts << io_handler.GetPrompt() << ' ' << line.c_str()
> 
> JDevlieghere wrote:
>> this won't work for things like unambiguous abbreviations like `sess save`. 
>> The command should do the saving.
> I don't think it's unreasonable to write to the "transcript" here, but the 
> string matching is obviously suboptimal. However, it's not clear to me why is 
> it even needed -- having the "save" command in the transcript does not 
> necessarily seem like a bad thing, and I believe the way it is implemented 
> means that the command will not show up in the session file that is currently 
> being saved (only in the subsequent ones).
> 
> 
> 
> Comment at: lldb/source/Interpreter/CommandInterpreter.cpp:2820
> +llvm::StringRef result_output = result.GetOutputData();
> +if (!result_output.empty())
> +  *m_session_transcripts << result_output;
> 
> These `!empty()` checks are pointless.
> 
> 
> 
> Comment at: lldb/source/Interpreter/CommandInterpreter.cpp:2827
> +
> +m_session_transcripts->Flush();
> +  }
> 
> As is this flush call.
> 
> 
> 
> Comment at: lldb/source/Interpreter/CommandInterpreter.cpp:2929
> +  Status error;
> +  user_id_t fd_dst = FileCache::GetInstance().OpenFile(
> +  FileSpec(output_file), flags, lldb::eFilePer

[Lldb-commits] [lldb] a976a7f - Disable this test for Windows.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-06-04T10:51:01-07:00
New Revision: a976a7fcae44ed5ca9e4f13735a4f91378169282

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

LOG: Disable this test for Windows.

The printf expression crashes with the message:

Attempted to dereference an invalid pointer

Someone who knows more about Windows should suggest how to fix this.

Added: 


Modified: 

lldb/test/API/functionalities/thread/state_after_expression/TestStateAfterExpression.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/thread/state_after_expression/TestStateAfterExpression.py
 
b/lldb/test/API/functionalities/thread/state_after_expression/TestStateAfterExpression.py
index 082b556dbdce..b108d53c9654 100644
--- 
a/lldb/test/API/functionalities/thread/state_after_expression/TestStateAfterExpression.py
+++ 
b/lldb/test/API/functionalities/thread/state_after_expression/TestStateAfterExpression.py
@@ -8,12 +8,13 @@
 import lldb
 import lldbsuite.test.lldbutil as lldbutil
 from lldbsuite.test.lldbtest import *
-
+from lldbsuite.test.decorators import *
 
 class TestStopReasonAfterExpression(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
 
+@skipIfWindows
 def test_thread_state_after_expr(self):
 self.build()
 self.main_source_file = lldb.SBFileSpec("main.cpp")



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

[Lldb-commits] [lldb] f4d4273 - Add a test for preserving state on the non-expr thread across expression evaluation.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-06-03T14:30:35-07:00
New Revision: f4d427326539f007b05378eaf66018c10b651ad0

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

LOG: Add a test for preserving state on the non-expr thread across expression 
evaluation.

There may be another test that tests this but I couldn't find one.

Added: 
lldb/test/API/functionalities/thread/state_after_expression/Makefile

lldb/test/API/functionalities/thread/state_after_expression/TestStateAfterExpression.py
lldb/test/API/functionalities/thread/state_after_expression/main.cpp

Modified: 


Removed: 




diff  --git 
a/lldb/test/API/functionalities/thread/state_after_expression/Makefile 
b/lldb/test/API/functionalities/thread/state_after_expression/Makefile
new file mode 100644
index ..d7aace51bc82
--- /dev/null
+++ b/lldb/test/API/functionalities/thread/state_after_expression/Makefile
@@ -0,0 +1,6 @@
+CXX_SOURCES := main.cpp
+CFLAGS_EXTRAS := -std=c++11
+
+ENABLE_THREADS := YES
+
+include Makefile.rules

diff  --git 
a/lldb/test/API/functionalities/thread/state_after_expression/TestStateAfterExpression.py
 
b/lldb/test/API/functionalities/thread/state_after_expression/TestStateAfterExpression.py
new file mode 100644
index ..082b556dbdce
--- /dev/null
+++ 
b/lldb/test/API/functionalities/thread/state_after_expression/TestStateAfterExpression.py
@@ -0,0 +1,53 @@
+"""
+Make sure the stop reason of a thread that did not run
+during an expression is not changed by running the expression
+"""
+
+
+
+import lldb
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+
+class TestStopReasonAfterExpression(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_thread_state_after_expr(self):
+self.build()
+self.main_source_file = lldb.SBFileSpec("main.cpp")
+self.do_test()
+
+def do_test(self):
+(target, process, thread, bkpt) = 
lldbutil.run_to_source_breakpoint(self,
+"Set a breakpoint here", self.main_source_file)
+
+self.assertEqual(bkpt.GetNumLocations(), 2, "Got two locations")
+
+# So now thread holds the main thread.  Continue to hit the
+# breakpoint again on the spawned thread:
+
+threads = lldbutil.continue_to_breakpoint(process, bkpt)
+self.assertEqual(len(threads), 1, "Hit the breakpoint the second time")
+other_thread = threads[0]
+
+self.assertNotEqual(thread.GetThreadID(), other_thread.GetThreadID(),
+"A 
diff erent thread")
+# Run an expression ONLY on other_thread.  Don't let thread run:
+options = lldb.SBExpressionOptions()
+options.SetTryAllThreads(False)
+options.SetStopOthers(True)
+
+result = thread.frames[0].EvaluateExpression('(int) 
printf("Hello\\n")', options)
+self.assertTrue(result.GetError().Success(),
+"Expression failed: 
'%s'"%(result.GetError().GetCString()))
+
+stop_reason = other_thread.GetStopReason()
+
+self.assertEqual(stop_reason, lldb.eStopReasonBreakpoint,
+ "Still records stopped at breakpoint: %s"
+ %(lldbutil.stop_reason_to_str(stop_reason)))
+self.assertEqual(other_thread.GetStopReasonDataAtIndex(0), 1,
+ "Still records stopped at right breakpoint")
+

diff  --git 
a/lldb/test/API/functionalities/thread/state_after_expression/main.cpp 
b/lldb/test/API/functionalities/thread/state_after_expression/main.cpp
new file mode 100644
index ..338232ece632
--- /dev/null
+++ b/lldb/test/API/functionalities/thread/state_after_expression/main.cpp
@@ -0,0 +1,14 @@
+#include 
+
+void thread_func() {
+  // Set a breakpoint here
+}
+
+int
+main()
+{
+  // Set a breakpoint here
+  std::thread stopped_thread(thread_func);
+  stopped_thread.join();
+  return 0;
+}



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

[Lldb-commits] [lldb] 723a1ca - Fix the crashlog.py script's use of the load_address property.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-05-28T09:55:40-07:00
New Revision: 723a1caa377b898ff3dc0897156f544feab99ac8

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

LOG: Fix the crashlog.py script's use of the load_address property.

This property is explicitly for use only in the interactive editor,
and NOT in commands.  It's use worked until we got more careful about
not leaving lldb.target lying around in the script interpreter.

I also added a quick sniff test for the save_crashlog command.


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

Added: 
lldb/test/API/macosx/save_crashlog/Makefile
lldb/test/API/macosx/save_crashlog/TestSaveCrashlog.py
lldb/test/API/macosx/save_crashlog/main.c

Modified: 
lldb/examples/python/crashlog.py

Removed: 




diff  --git a/lldb/examples/python/crashlog.py 
b/lldb/examples/python/crashlog.py
index b7b62acc60ef..1c1602b0131e 100755
--- a/lldb/examples/python/crashlog.py
+++ b/lldb/examples/python/crashlog.py
@@ -791,11 +791,11 @@ def save_crashlog(debugger, command, exe_ctx, result, 
dict):
 block_range = block.range[frame.addr]
 if block_range:
 block_start_addr = block_range[0]
-frame_offset = frame_pc - block_start_addr.load_addr
+frame_offset = frame_pc - 
block_start_addr.GetLoadAddress(target)
 else:
-frame_offset = frame_pc - frame.function.addr.load_addr
+frame_offset = frame_pc - 
frame.function.addr.GetLoadAddress(target)
 elif frame.symbol:
-frame_offset = frame_pc - frame.symbol.addr.load_addr
+frame_offset = frame_pc - 
frame.symbol.addr.GetLoadAddress(target)
 out_file.write(
 '%-3u %-32s 0x%16.16x %s' %
 (frame_idx, frame.module.file.basename, frame_pc, 
frame.name))

diff  --git a/lldb/test/API/macosx/save_crashlog/Makefile 
b/lldb/test/API/macosx/save_crashlog/Makefile
new file mode 100644
index ..695335e068c0
--- /dev/null
+++ b/lldb/test/API/macosx/save_crashlog/Makefile
@@ -0,0 +1,4 @@
+C_SOURCES := main.c
+CFLAGS_EXTRAS := -std=c99
+
+include Makefile.rules

diff  --git a/lldb/test/API/macosx/save_crashlog/TestSaveCrashlog.py 
b/lldb/test/API/macosx/save_crashlog/TestSaveCrashlog.py
new file mode 100644
index ..c86294490f61
--- /dev/null
+++ b/lldb/test/API/macosx/save_crashlog/TestSaveCrashlog.py
@@ -0,0 +1,68 @@
+"""
+Test that the save_crashlog command functions
+"""
+
+
+import os
+import lldb
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+
+
+class TestSaveCrashlog(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+# If your test case doesn't stress debug info, the
+# set this to true.  That way it won't be run once for
+# each debug info format.
+NO_DEBUG_INFO_TESTCASE = True
+
+@skipUnlessDarwin
+def test_save_crashlog(self):
+"""There can be many tests in a test case - describe this test here."""
+self.build()
+self.main_source_file = lldb.SBFileSpec("main.c")
+self.save_crashlog()
+
+def save_crashlog(self):
+
+(target, process, thread, bkpt) = 
lldbutil.run_to_source_breakpoint(self,
+   "I was called", self.main_source_file)
+
+self.runCmd("command script import lldb.macosx.crashlog")
+out_file = os.path.join(self.getBuildDir(), "crash.log")
+self.runCmd("save_crashlog '%s'"%(out_file))
+
+# Make sure we wrote the file:
+self.assertTrue(os.path.exists(out_file), "We wrote our file")
+
+# Now scan the file to make sure it looks right:
+# First get a few facts we'll use:
+exe_module = target.FindModule(target.GetExecutable())
+uuid_str = exe_module.GetUUIDString()
+
+# We'll set these to true when we find the elements in the file
+found_call_me = False
+found_main_line = False
+found_thread_header = False
+found_uuid_str = False
+
+with open(out_file, "r") as f:
+# We want to see a line with
+for line in f:
+if "Thread 0:" in line:
+found_thread_header = True
+if "call_me" in line and "main.c:" in line:
+found_call_me = True
+if "main" in line and "main.c:" in line:
+found_main_line = True
+if uuid_str in line and "a.out" in line:
+found_uuid_str = True
+
+self.assertTrue(found_thread_header, "Found thr

Re: [Lldb-commits] [lldb] 053b063 - [lldb] Increase timeout in TestExitDuringExpression

[Jim Ingham via lldb-commits]

I set the timeouts low just to keep the test from taking too long.  Beyond that 
there’s no harm in bumping them up till they pass consistently.

I messed with the timeouts and reran the test a bunch of times till it was 
stable for me, but I have a pretty fast mac, so apparently that wasn’t a good 
test…

I don’t see a way to do this without timeouts, however…

Thanks for fixing this.

Jim


> On May 22, 2020, at 3:47 AM, Pavel Labath via lldb-commits 
>  wrote:
> 
> 
> Author: Pavel Labath
> Date: 2020-05-22T12:47:34+02:00
> New Revision: 053b0634ea93b1ed7993adf34730bd752e9d84ec
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/053b0634ea93b1ed7993adf34730bd752e9d84ec
> DIFF: 
> https://github.com/llvm/llvm-project/commit/053b0634ea93b1ed7993adf34730bd752e9d84ec.diff
> 
> LOG: [lldb] Increase timeout in TestExitDuringExpression
> 
> 200 microseconds is not enough time for any expression to execute
> reliably. On linux, calling pthread_exit can result in call to dlopen,
> which cannot complete in that time, particularly when running under a
> debugger.
> 
> On linux, this test failed all the time, on macos, about two thirds of
> runs were failing.  This patch increases the timeout to 100ms, which is
> enough to get it passing reliably on linux, though I wouldn't be
> surprised if an even bigger timeout would be needed for remote test
> runs.
> 
> Added: 
> 
> 
> Modified: 
>lldb/test/API/functionalities/thread/exit_during_expression/main.c
> 
> Removed: 
> 
> 
> 
> 
> diff  --git 
> a/lldb/test/API/functionalities/thread/exit_during_expression/main.c 
> b/lldb/test/API/functionalities/thread/exit_during_expression/main.c
> index 66b6018976cf..a3bf53915a03 100644
> --- a/lldb/test/API/functionalities/thread/exit_during_expression/main.c
> +++ b/lldb/test/API/functionalities/thread/exit_during_expression/main.c
> @@ -3,7 +3,7 @@
> #include 
> #include 
> 
> -static unsigned int g_timeout = 200;
> +static unsigned int g_timeout = 10;
> 
> int function_to_call() {
> 
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

Re: [Lldb-commits] [lldb] 8a6333e - [lldb/REPL] Fix unhandled switch case

[Jim Ingham via lldb-commits]

Sorry I missed that.  That seems fine.  In the dedicated REPL, you’re probably 
dead at this point, but you can do “expr —repl --” in which case we’ll pick 
whatever thread on to run your expression, adding the results to the REPL 
context, so it could happen there and you might not be all the way toast.  So 
just returning an error is fine.

Jim

> On May 21, 2020, at 11:23 PM, Jonas Devlieghere  wrote:
> 
> Jim, does this look correct to you?
> 
> On Thu, May 21, 2020 at 11:22 PM Jonas Devlieghere via lldb-commits 
> mailto:lldb-commits@lists.llvm.org>> wrote:
> 
> Author: Jonas Devlieghere
> Date: 2020-05-21T23:22:17-07:00
> New Revision: 8a6333ef38088b65224bc021a14f0a123a29
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/8a6333ef38088b65224bc021a14f0a123a29
>  
> 
> DIFF: 
> https://github.com/llvm/llvm-project/commit/8a6333ef38088b65224bc021a14f0a123a29.diff
>  
> 
> 
> LOG: [lldb/REPL] Fix unhandled switch case
> 
> Fix warning: enumeration value 'eExpressionThreadVanished' not handled
> in switch [-Wswitch]
> 
> Added: 
> 
> 
> Modified: 
> lldb/source/Expression/REPL.cpp
> 
> Removed: 
> 
> 
> 
> 
> diff  --git a/lldb/source/Expression/REPL.cpp 
> b/lldb/source/Expression/REPL.cpp
> index 6c9792c6e837..a55fe09bdeb6 100644
> --- a/lldb/source/Expression/REPL.cpp
> +++ b/lldb/source/Expression/REPL.cpp
> @@ -388,6 +388,11 @@ void REPL::IOHandlerInputComplete(IOHandler &io_handler, 
> std::string &code) {
>  error_sp->Printf("error: stopped for debug -- %s\n",
>   error.AsCString());
>  break;
> +  case lldb::eExpressionThreadVanished:
> +// Shoulnd't happen???
> +error_sp->Printf("error: expression thread vanished -- %s\n",
> + error.AsCString());
> +break;
>}
>  }
> 
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org 
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits 
> 

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

[Lldb-commits] [lldb] 54c2c2a - Maybe I need ENABLE_THREADS in the Makefile.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-05-21T18:38:49-07:00
New Revision: 54c2c2add7ad42ce1910a276cd1cd2912af4cddd

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

LOG: Maybe I need ENABLE_THREADS in the Makefile.

Added: 


Modified: 
lldb/test/API/functionalities/thread/exit_during_expression/Makefile

lldb/test/API/functionalities/thread/exit_during_expression/TestExitDuringExpression.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/thread/exit_during_expression/Makefile 
b/lldb/test/API/functionalities/thread/exit_during_expression/Makefile
index 695335e068c0..bb8ff4feac81 100644
--- a/lldb/test/API/functionalities/thread/exit_during_expression/Makefile
+++ b/lldb/test/API/functionalities/thread/exit_during_expression/Makefile
@@ -1,4 +1,6 @@
 C_SOURCES := main.c
 CFLAGS_EXTRAS := -std=c99
 
+ENABLE_THREADS := YES
+
 include Makefile.rules

diff  --git 
a/lldb/test/API/functionalities/thread/exit_during_expression/TestExitDuringExpression.py
 
b/lldb/test/API/functionalities/thread/exit_during_expression/TestExitDuringExpression.py
index 76cdd62a0ff2..bfdfdf53cdb1 100644
--- 
a/lldb/test/API/functionalities/thread/exit_during_expression/TestExitDuringExpression.py
+++ 
b/lldb/test/API/functionalities/thread/exit_during_expression/TestExitDuringExpression.py
@@ -14,8 +14,6 @@ class TestExitDuringExpression(TestBase):
 
 NO_DEBUG_INFO_TESTCASE = True
 
-# The test file doesn't build on Linux: "undefined reference to 
pthread_create"
-@skipIfLinux 
 @skipIfWindows
 def test_exit_before_one_thread_unwind(self):
 """Test the case where we exit within the one thread timeout"""



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

[Lldb-commits] [lldb] 1583766 - This very simple .c file is failing on the Debian bot wit the error

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-05-21T18:26:01-07:00
New Revision: 1583766ed23b707898e872728783f054ede47ca8

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

LOG: This very simple .c file is failing on the Debian bot wit the error

undefined reference to pthread_create

I skipped the test till I can figure out why this didn't build.

Added: 


Modified: 

lldb/test/API/functionalities/thread/exit_during_expression/TestExitDuringExpression.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/thread/exit_during_expression/TestExitDuringExpression.py
 
b/lldb/test/API/functionalities/thread/exit_during_expression/TestExitDuringExpression.py
index bfdfdf53cdb1..76cdd62a0ff2 100644
--- 
a/lldb/test/API/functionalities/thread/exit_during_expression/TestExitDuringExpression.py
+++ 
b/lldb/test/API/functionalities/thread/exit_during_expression/TestExitDuringExpression.py
@@ -14,6 +14,8 @@ class TestExitDuringExpression(TestBase):
 
 NO_DEBUG_INFO_TESTCASE = True
 
+# The test file doesn't build on Linux: "undefined reference to 
pthread_create"
+@skipIfLinux 
 @skipIfWindows
 def test_exit_before_one_thread_unwind(self):
 """Test the case where we exit within the one thread timeout"""



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

[Lldb-commits] [lldb] dbbed97 - Handle the case where a thread exits while we are running a function on it.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-05-21T17:55:53-07:00
New Revision: dbbed971e3a282f44242297b75a527256eb862dc

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

LOG: Handle the case where a thread exits while we are running a function on it.

Added: 
lldb/test/API/functionalities/thread/exit_during_expression/Makefile

lldb/test/API/functionalities/thread/exit_during_expression/TestExitDuringExpression.py
lldb/test/API/functionalities/thread/exit_during_expression/main.c

Modified: 
lldb/include/lldb/lldb-enumerations.h
lldb/source/Expression/FunctionCaller.cpp
lldb/source/Expression/LLVMUserExpression.cpp
lldb/source/Target/Process.cpp

Removed: 




diff  --git a/lldb/include/lldb/lldb-enumerations.h 
b/lldb/include/lldb/lldb-enumerations.h
index e5032a6cd97f..b3e8d604913f 100644
--- a/lldb/include/lldb/lldb-enumerations.h
+++ b/lldb/include/lldb/lldb-enumerations.h
@@ -269,7 +269,8 @@ enum ExpressionResults {
   eExpressionHitBreakpoint,
   eExpressionTimedOut,
   eExpressionResultUnavailable,
-  eExpressionStoppedForDebug
+  eExpressionStoppedForDebug,
+  eExpressionThreadVanished
 };
 
 enum SearchDepth {

diff  --git a/lldb/source/Expression/FunctionCaller.cpp 
b/lldb/source/Expression/FunctionCaller.cpp
index f4b02268fd1a..26ab4bfaff53 100644
--- a/lldb/source/Expression/FunctionCaller.cpp
+++ b/lldb/source/Expression/FunctionCaller.cpp
@@ -364,8 +364,9 @@ lldb::ExpressionResults FunctionCaller::ExecuteFunction(
 if (return_value != lldb::eExpressionCompleted) {
   LLDB_LOGF(log,
 "== [FunctionCaller::ExecuteFunction] Execution of \"%s\" "
-"completed abnormally ==",
-m_name.c_str());
+"completed abnormally: %s ==",
+m_name.c_str(),
+Process::ExecutionResultAsCString(return_value));
 } else {
   LLDB_LOGF(log,
 "== [FunctionCaller::ExecuteFunction] Execution of \"%s\" "

diff  --git a/lldb/source/Expression/LLVMUserExpression.cpp 
b/lldb/source/Expression/LLVMUserExpression.cpp
index d7958a50f9bb..187b427e66aa 100644
--- a/lldb/source/Expression/LLVMUserExpression.cpp
+++ b/lldb/source/Expression/LLVMUserExpression.cpp
@@ -134,6 +134,10 @@ LLVMUserExpression::DoExecute(DiagnosticManager 
&diagnostic_manager,
   return lldb::eExpressionSetupError;
 }
 
+// Store away the thread ID for error reporting, in case it exits
+// during execution:
+lldb::tid_t expr_thread_id = exe_ctx.GetThreadRef().GetID();
+
 Address wrapper_address(m_jit_start_addr);
 
 std::vector args;
@@ -223,6 +227,14 @@ LLVMUserExpression::DoExecute(DiagnosticManager 
&diagnostic_manager,
   "Use \"thread return -x\" to return to the state before expression "
   "evaluation.");
   return execution_result;
+} else if (execution_result == lldb::eExpressionThreadVanished) {
+  diagnostic_manager.Printf(
+  eDiagnosticSeverityError,
+  "Couldn't complete execution; the thread "
+  "on which the expression was being run: 0x%" PRIx64
+  " exited during its execution.", 
+  expr_thread_id);
+  return execution_result;
 } else if (execution_result != lldb::eExpressionCompleted) {
   diagnostic_manager.Printf(
   eDiagnosticSeverityError, "Couldn't execute function; result was %s",

diff  --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index 7bd53af985d4..0eb9866e4a4b 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -4652,13 +4652,27 @@ GetExpressionTimeout(const EvaluateExpressionOptions 
&options,
 }
 
 static llvm::Optional
-HandleStoppedEvent(Thread &thread, const ThreadPlanSP &thread_plan_sp,
+HandleStoppedEvent(lldb::tid_t thread_id, const ThreadPlanSP &thread_plan_sp,
RestorePlanState &restorer, const EventSP &event_sp,
EventSP &event_to_broadcast_sp,
-   const EvaluateExpressionOptions &options, bool 
handle_interrupts) {
+   const EvaluateExpressionOptions &options,
+   bool handle_interrupts) {
   Log *log = GetLogIfAnyCategoriesSet(LIBLLDB_LOG_STEP | LIBLLDB_LOG_PROCESS);
 
-  ThreadPlanSP plan = thread.GetCompletedPlan();
+  ThreadSP thread_sp = thread_plan_sp->GetTarget()
+   .GetProcessSP()
+   ->GetThreadList()
+   .FindThreadByID(thread_id);
+  if (!thread_sp) {
+LLDB_LOG(log,
+ "The thread on which we were running the "
+ "expression: tid = {0}, exited while "
+ "the expression was running.",
+ thread_id);
+return eExpressionThreadVanished;
+  }
+
+  ThreadPlanSP plan = thr

Re: [Lldb-commits] [lldb] 1cbd1b8 - Revert "[lldb] Don't dissasemble large functions by default"

[Jim Ingham via lldb-commits]

I’m pretty sure all you need to do is add a —force to the disassemble command 
in TestFoundationDisassembly.py.

Jim


> On May 14, 2020, at 2:16 PM, via lldb-commits  
> wrote:
> 
> 
> Author: shafik
> Date: 2020-05-14T14:15:51-07:00
> New Revision: 1cbd1b8f692df7742efb9114510688045d901f96
> 
> URL: 
> https://github.com/llvm/llvm-project/commit/1cbd1b8f692df7742efb9114510688045d901f96
> DIFF: 
> https://github.com/llvm/llvm-project/commit/1cbd1b8f692df7742efb9114510688045d901f96.diff
> 
> LOG: Revert "[lldb] Don't dissasemble large functions by default"
> 
> This reverts commit f665e80c023ec52557f55d7eeaf34471e4c6fa0d.
> 
> Reverting because it breaks TestFoundationDisassembly.py
> 
> Added: 
> 
> 
> Modified: 
>lldb/source/Commands/CommandObjectDisassemble.cpp
>lldb/source/Commands/CommandObjectDisassemble.h
>lldb/source/Commands/Options.td
>lldb/test/Shell/Commands/Inputs/command-disassemble.lldbinit
>lldb/test/Shell/Commands/command-disassemble-process.yaml
>lldb/test/Shell/Commands/command-disassemble.s
> 
> Removed: 
> 
> 
> 
> 
> diff  --git a/lldb/source/Commands/CommandObjectDisassemble.cpp 
> b/lldb/source/Commands/CommandObjectDisassemble.cpp
> index d522d63b6d0d..511cd6995404 100644
> --- a/lldb/source/Commands/CommandObjectDisassemble.cpp
> +++ b/lldb/source/Commands/CommandObjectDisassemble.cpp
> @@ -21,9 +21,8 @@
> #include "lldb/Target/StackFrame.h"
> #include "lldb/Target/Target.h"
> 
> -static constexpr unsigned default_disasm_byte_size = 32;
> -static constexpr unsigned default_disasm_num_ins = 4;
> -static constexpr unsigned large_function_threshold = 4000;
> +#define DEFAULT_DISASM_BYTE_SIZE 32
> +#define DEFAULT_DISASM_NUM_INS 4
> 
> using namespace lldb;
> using namespace lldb_private;
> @@ -144,10 +143,6 @@ Status 
> CommandObjectDisassemble::CommandOptions::SetOptionValue(
> }
>   } break;
> 
> -  case '\x01':
> -force = true;
> -break;
> -
>   default:
> llvm_unreachable("Unimplemented option");
>   }
> @@ -191,7 +186,6 @@ void 
> CommandObjectDisassemble::CommandOptions::OptionParsingStarting(
> 
>   arch.Clear();
>   some_location_specified = false;
> -  force = false;
> }
> 
> Status CommandObjectDisassemble::CommandOptions::OptionParsingFinished(
> @@ -220,21 +214,6 @@ CommandObjectDisassemble::CommandObjectDisassemble(
> 
> CommandObjectDisassemble::~CommandObjectDisassemble() = default;
> 
> -llvm::Error CommandObjectDisassemble::CheckRangeSize(const AddressRange 
> &range,
> - llvm::StringRef what) {
> -  if (m_options.num_instructions > 0 || m_options.force ||
> -  range.GetByteSize() < large_function_threshold)
> -return llvm::Error::success();
> -  StreamString msg;
> -  msg << "Not disassembling " << what << " because it is very large ";
> -  range.Dump(&msg, &GetSelectedTarget(), Address::DumpStyleLoadAddress,
> - Address::DumpStyleFileAddress);
> -  msg << ". To disassemble specify an instruction count limit, start/stop "
> - "addresses or use the --force option.";
> -  return llvm::createStringError(llvm::inconvertibleErrorCode(),
> - msg.GetString());
> -}
> -
> llvm::Expected>
> CommandObjectDisassemble::GetContainingAddressRanges() {
>   std::vector ranges;
> @@ -275,9 +254,6 @@ CommandObjectDisassemble::GetContainingAddressRanges() {
> "Could not find function bounds for address 0x%" PRIx64,
> m_options.symbol_containing_addr);
>   }
> -
> -  if (llvm::Error err = CheckRangeSize(ranges[0], "the function"))
> -return std::move(err);
>   return ranges;
> }
> 
> @@ -297,10 +273,8 @@ CommandObjectDisassemble::GetCurrentFunctionRanges() {
>   else if (sc.symbol && sc.symbol->ValueIsAddress()) {
> range = {sc.symbol->GetAddress(), sc.symbol->GetByteSize()};
>   } else
> -range = {frame->GetFrameCodeAddress(), default_disasm_byte_size};
> +range = {frame->GetFrameCodeAddress(), DEFAULT_DISASM_BYTE_SIZE};
> 
> -  if (llvm::Error err = CheckRangeSize(range, "the current function"))
> -return std::move(err);
>   return std::vector{range};
> }
> 
> @@ -324,7 +298,7 @@ CommandObjectDisassemble::GetCurrentLineRanges() {
> }
> 
> llvm::Expected>
> -CommandObjectDisassemble::GetNameRanges(CommandReturnObject &result) {
> +CommandObjectDisassemble::GetNameRanges() {
>   ConstString name(m_options.func_name.c_str());
>   const bool include_symbols = true;
>   const bool include_inlines = true;
> @@ -335,7 +309,6 @@ 
> CommandObjectDisassemble::GetNameRanges(CommandReturnObject &result) {
>   name, eFunctionNameTypeAuto, include_symbols, include_inlines, sc_list);
> 
>   std::vector ranges;
> -  llvm::Error range_errs = llvm::Error::success();
>   AddressRange range;
>   const uint32_t scope =
>   eSymbolContextBlock | eSymbolContextFunction | eSymbolContextSymbol;
> @@ -344,21 +317,14 @@ 
> CommandObjectDisa

Re: [Lldb-commits] [PATCH] D78807: Fix gendered documentation

[Jim Ingham via lldb-commits]

A lot of our comments and documentation was written a while ago when the “good” 
practice was to be careful to use “he” and “she” in equal measure when 
referring to our users.  The consensus has shifted to using “they” instead, so 
there are probably a bunch of other places using he and she.  Please feel free 
to fix this wherever you see it!

Thanks!

Jim

> On Apr 24, 2020, at 9:43 AM, Jonas Devlieghere via Phabricator via 
> lldb-commits  wrote:
> 
> JDevlieghere accepted this revision.
> JDevlieghere added a comment.
> 
> Thank you!
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D78807/new/
> 
> https://reviews.llvm.org/D78807
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

Re: [Lldb-commits] [PATCH] D78421: Fix out of sync source code/executable when debugging

[Jim Ingham via lldb-commits]

Yes, to do it right you should do that.  I think it would still be worthwhile 
to first check whether the current frame’s source file is the one being asked 
for, since that is a very common way to get to source files and that would make 
going from source file -> module very cheap.  But otherwise, I can’t see a way 
around finding the module the source file is actually used in and comparing 
times with that.  Note, theoretically, you would also have to handle with the 
case where module A used an old version of the file and module B a new one - 
for instance when building two libraries with a common header file.  Not sure 
what a good thing to do there is, maybe just warn?

Jim


> On Apr 21, 2020, at 2:07 AM, Martin Schmidt via Phabricator 
>  wrote:
> 
> n1tram1 added a comment.
> 
> In D78421#1993030 , @jingham wrote:
> 
>> So you check the currently selected frame's module - which is libbar.dylib 
>> and find that it was built before FileFromNotBar.c and would show me the old 
>> version.
>> 
>> Showing me the latest version of the file is not great, but totally 
>> explicable.  Whereas this error, when it happens, would be confusing and 
>> hard to understand.
> 
> 
> So instead I should try to find which module the source file belongs to and 
> check that module's modification time (instead of getting the currently 
> selected frame) ?
> 
> 
> Repository:
> rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
> https://reviews.llvm.org/D78421/new/
> 
> https://reviews.llvm.org/D78421
> 
> 
> 

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

[Lldb-commits] [lldb] aa4b37b - Convert the ThreadPlanCommands test to use a scripted plan

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-04-10T18:15:03-07:00
New Revision: aa4b37b2acda8f0879ed5507e1a732c37e6ec5aa

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

LOG: Convert the ThreadPlanCommands test to use a scripted plan
that pushes a step over plan.  Relax the listing checker
so it will look past any entries after the ones listed in
the input patterns.  Then for the internal plans just check
for the StepOver plan that our scripted plan pushes, and look past
any others.

This should make the test more robust on systems that don't use the
step-in then push a step-out plan to step over a function.

Added: 
lldb/test/API/functionalities/thread_plan/wrap_step_over.py

Modified: 
lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py 
b/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
index ddc88cce75f1..ff3b04d49e55 100644
--- a/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
+++ b/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
@@ -46,24 +46,7 @@ def check_list_output(self, command, active_plans = [], 
completed_plans = [], di
 self.assertTrue(result.Succeeded(), "command: '%s' failed: 
'%s'"%(command, result.GetError()))
 result_arr = result.GetOutput().splitlines()
 num_results = len(result_arr)
-
-# Match the expected number of elements.
-# Adjust the count for the number of header lines we aren't matching:
-fudge = 0
 
-if num_completed == 0 and num_discarded == 0:
-# The fudge is 3: Thread header, Active Plan header and base plan
-fudge = 3
-elif num_completed == 0 or num_discarded == 0:
-# The fudge is 4: The above plus either the Completed or Discarded 
Plan header:
-fudge = 4
-else:
-# The fudge is 5 since we have both headers:
-fudge = 5
-
-self.assertEqual(num_results, num_active + num_completed + 
num_discarded + fudge,
- "Too many elements in match arrays for: 
\n%s\n"%result.GetOutput())
-
 # Now iterate through the results array and pick out the results.
 result_idx = 0
 self.assertIn("thread #", result_arr[result_idx], "Found thread 
header") ; result_idx += 1
@@ -71,29 +54,47 @@ def check_list_output(self, command, active_plans = [], 
completed_plans = [], di
 self.assertIn("Element 0: Base thread plan", result_arr[result_idx], 
"Found base plan") ; result_idx += 1
 
 for text in active_plans:
-self.assertFalse("Completed plan stack" in result_arr[result_idx], 
"Found Completed header too early.")
 self.assertIn(text, result_arr[result_idx], "Didn't find active 
plan: %s"%(text)) ; result_idx += 1
+
 
 if len(completed_plans) > 0:
-self.assertIn("Completed plan stack:", result_arr[result_idx], 
"Found completed plan stack header") ; result_idx += 1
+# First consume any remaining active plans:
+while not "Completed plan stack:" in result_arr[result_idx]:
+result_idx += 1
+if result_idx == num_results:
+self.fail("There should have been completed plans, but I 
never saw the completed stack header")
+# We are at the Completed header, skip it:
+result_idx += 1
 for text in completed_plans:
 self.assertIn(text, result_arr[result_idx], "Didn't find 
completed plan: %s"%(text)) ; result_idx += 1
 
 if len(discarded_plans) > 0:
-self.assertIn("Discarded plan stack:", result_arr[result_idx], 
"Found discarded plan stack header") ; result_idx += 1
+# First consume any remaining completed plans:
+while not "Discarded plan stack:" in result_arr[result_idx]:
+result_idx += 1
+if result_idx == num_results:
+self.fail("There should have been discarded plans, but I 
never saw the discarded stack header")
+
+# We are at the Discarded header, skip it:
+result_idx += 1
 for text in discarded_plans:
-self.assertIn(text, result_arr[result_idx], "Didn't find 
completed plan: %s"%(text)) ; result_idx += 1
+self.assertIn(text, result_arr[result_idx], "Didn't find 
discarded plan: %s"%(text)) ; result_idx += 1
 
 
 def thread_plan_test(self):
 (target, process, thread, bkpt) = 
lldbutil.run_to_source_breakpoint(self,
"Set a breakpoint here", 
self.main_source_file)
 
-# Now set a breakpoint i

[Lldb-commits] [lldb] f7de4b5 - Thread Plans pushed by a scripted plan should be private plans.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-04-10T18:15:03-07:00
New Revision: f7de4b5d6bce8c33ac3e18a41abcf5268a29f461

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

LOG: Thread Plans pushed by a scripted plan should be private plans.

If a plan is not private, "thread plan discard" can discard it.  It would
not be hard to write reliable scripted plan if its subplans could get
removed out from under it.

Added: 


Modified: 
lldb/source/API/SBThreadPlan.cpp

Removed: 




diff  --git a/lldb/source/API/SBThreadPlan.cpp 
b/lldb/source/API/SBThreadPlan.cpp
index b93c31763e59..1a947bbc2608 100644
--- a/lldb/source/API/SBThreadPlan.cpp
+++ b/lldb/source/API/SBThreadPlan.cpp
@@ -237,7 +237,9 @@ SBThreadPlan SBThreadPlan::QueueThreadPlanForStepOverRange(
 
 if (plan_status.Fail())
   error.SetErrorString(plan_status.AsCString());
-
+else
+  plan.m_opaque_sp->SetPrivate(true);
+
 return LLDB_RECORD_RESULT(plan);
   } else {
 return LLDB_RECORD_RESULT(SBThreadPlan());
@@ -281,6 +283,8 @@ SBThreadPlan::QueueThreadPlanForStepInRange(SBAddress 
&sb_start_address,
 
 if (plan_status.Fail())
   error.SetErrorString(plan_status.AsCString());
+else
+  plan.m_opaque_sp->SetPrivate(true);
 
 return LLDB_RECORD_RESULT(plan);
   } else {
@@ -321,6 +325,8 @@ SBThreadPlan::QueueThreadPlanForStepOut(uint32_t 
frame_idx_to_step_to,
 
 if (plan_status.Fail())
   error.SetErrorString(plan_status.AsCString());
+else
+  plan.m_opaque_sp->SetPrivate(true);
 
 return LLDB_RECORD_RESULT(plan);
   } else {
@@ -356,6 +362,8 @@ SBThreadPlan 
SBThreadPlan::QueueThreadPlanForRunToAddress(SBAddress sb_address,
 
 if (plan_status.Fail())
   error.SetErrorString(plan_status.AsCString());
+else
+  plan.m_opaque_sp->SetPrivate(true);
 
 return LLDB_RECORD_RESULT(plan);
   } else {
@@ -390,6 +398,8 @@ SBThreadPlan::QueueThreadPlanForStepScripted(const char 
*script_class_name,
 
 if (plan_status.Fail())
   error.SetErrorString(plan_status.AsCString());
+else
+  plan.m_opaque_sp->SetPrivate(true);
 
 return LLDB_RECORD_RESULT(plan);
   } else {
@@ -415,6 +425,8 @@ SBThreadPlan::QueueThreadPlanForStepScripted(const char 
*script_class_name,
 
 if (plan_status.Fail())
   error.SetErrorString(plan_status.AsCString());
+else
+  plan.m_opaque_sp->SetPrivate(true);
 
 return LLDB_RECORD_RESULT(plan);
   } else {



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

Re: [Lldb-commits] [lldb] 3775be2 - Target: correct the return value for `GetImageAddrFromToken`

[Jim Ingham via lldb-commits]

This should be easy to test.  If you have a running process, and haven’t called 
“process load” then:

(lldb) process unload 12345

Should return the error:

failed to unload image: invalid image token

But instead on x86_64 it returns the error:

failed to unload image: expression failed: "dlclose((void *)0x)”

Should be enough to run process unload with a bogus token and make sure the 
error is “invalid image token”.

Jim



> On Apr 6, 2020, at 6:48 PM, Shafik Yaghmour via lldb-commits 
>  wrote:
> 
> Hello Saleem,
> 
> I am not familiar with this part of the code but is there an easy way to test 
> this failure? We should add a test to make sure we don’t break this 
> accidentally in the future.
> 
> Thank you!
> 
>> On Apr 6, 2020, at 5:38 PM, Saleem Abdulrasool via lldb-commits 
>>  wrote:
>> 
>> 
>> Author: Saleem Abdulrasool
>> Date: 2020-04-06T17:37:57-07:00
>> New Revision: 3775be2d8e17aaeae62ab83ded005867f4bf70ac
>> 
>> URL: 
>> https://github.com/llvm/llvm-project/commit/3775be2d8e17aaeae62ab83ded005867f4bf70ac
>> DIFF: 
>> https://github.com/llvm/llvm-project/commit/3775be2d8e17aaeae62ab83ded005867f4bf70ac.diff
>> 
>> LOG: Target: correct the return value for `GetImageAddrFromToken`
>> 
>> We would return `LLDB_INVALID_IMAGE_TOKEN` for the address rather than
>> the correct value of `LLDB_IMAGE_ADDRESS`.  This would result in the
>> check for the return value to silently pass on x64 as the invalid
>> address and invalid token are of different sizes (`size_t` vs
>> `uintprr_t`).  This corrects the return value to `LLDB_INVALID_ADDRESS`
>> and addresses the rest to reset the mapped address to the invalid value.
>> 
>> This was found by inspection when trying to implement module support for
>> Windows.
>> 
>> Added: 
>> 
>> 
>> Modified: 
>>   lldb/source/Target/Process.cpp
>> 
>> Removed: 
>> 
>> 
>> 
>> 
>> diff  --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
>> index a3776f95..7797a4c60964 100644
>> --- a/lldb/source/Target/Process.cpp
>> +++ b/lldb/source/Target/Process.cpp
>> @@ -5796,12 +5796,12 @@ size_t Process::AddImageToken(lldb::addr_t 
>> image_ptr) {
>> lldb::addr_t Process::GetImagePtrFromToken(size_t token) const {
>>  if (token < m_image_tokens.size())
>>return m_image_tokens[token];
>> -  return LLDB_INVALID_IMAGE_TOKEN;
>> +  return LLDB_INVALID_ADDRESS;
>> }
>> 
>> void Process::ResetImageToken(size_t token) {
>>  if (token < m_image_tokens.size())
>> -m_image_tokens[token] = LLDB_INVALID_IMAGE_TOKEN;
>> +m_image_tokens[token] = LLDB_INVALID_ADDRESS;
>> }
>> 
>> Address
>> 
>> 
>> 
>> ___
>> lldb-commits mailing list
>> lldb-commits@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

Re: [Lldb-commits] [PATCH] D77444: [commands] Support autorepeat in SBCommands

[Jim Ingham via lldb-commits]

Then only time that I can find where I customized the string based on the 
incoming full command was for “source list” because I needed to know whether 
the listing was going forward or backward, so I needed to write that into the 
“keep doing what you were doing” command.  That could have also been 
implemented by remembering the direction as well as the “current source 
location” internally, and then have “source list” mean “keep going the 
direction you were going.”  So I don’t think dynamically constructing the next 
command string is necessary to cover the needed cases.

BTW, I thought when a command returned the command string for the next command, 
the command interpreter prepended it with the chain of parent commands 
containing the command that was presenting the “next command string”.  If it 
doesn’t do that, it probably should.  A command shouldn’t really know where it 
is sitting in the command hierarchy, so somebody has to do that for it.  

I don’t know of a case where a command would want its repeat command to be a 
wholly different command.  That seems odd, but if we do find we need that 
internally, we could add some way of saying “this command is not a variant of 
me…”  But in any case, for these purposes, it seems like the three useful cases 
are really “no repeat”, “repeat the command I was given” and “invoke my 
continue-from-where-I-left-off” command - which by convention is the command 
with no arguments.  If we make sure that when the repeat command is actually 
used the command interpreter adds the command’s parents, then I think we could 
do this with an enum.

Jim


> On Apr 6, 2020, at 11:57 AM, walter erquinigo via Phabricator 
>  wrote:
> 
> wallace updated this revision to Diff 255426.
> wallace added a comment.
> Herald added a subscriber: mgorny.
> 
> - Moved the test to gtest. It's much better this way and I learned gtest
> - Changed the API. Some notes:
> 
> Within the scope of a subcommand, the subcommand doesn't know the parent's
> command name. It only knows its own name and it doesn't have any referrence to
> its parent. That makes it very difficult to implement an enum option for
> eCommandNameRepeat, as @jingham suggested. The GetRepeatCommand signature also
> doesn't provide useful info about the parsed arguments.
> 
> I took a look at the existing implementations for GetRepeatCommand, and it 
> seems
> that most of them just return nullptr, "", or the same command without flags.
> 
> I don't want to change any existing core command interpreter function, so I
> think that a simple API that covers most of the cases is just providing 
> nullptr
> for repeating the same command, "" for not repeating, or a custom string for
> any other case. If in the future anyone needs something very customized, a new
> override could be created, but I don't think this will happen anytime soon.
> 
> Another option is to provide a callback function instead of a string, but I
> don't know if it's too much.
> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D77444/new/
> 
> https://reviews.llvm.org/D77444
> 
> Files:
>  lldb/include/lldb/API/SBCommandInterpreter.h
>  lldb/source/API/SBCommandInterpreter.cpp
>  lldb/unittests/Interpreter/CMakeLists.txt
>  lldb/unittests/Interpreter/TestAutoRepeat.cpp
> 
> 

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

Re: [Lldb-commits] [lldb] b6cd964 - Fix typo in xfail decorator for lldb thread plan list tests

[Jim Ingham via lldb-commits]

Yes.  Now that I think about it a little more, I’m a bit surprised that on most 
platforms we do have to step in & back out again to step over this function.  
That’s what we always used to do, but the work Greg & Co. did a little while 
back added the assumption that call’s return to the PC directly following the 
call, so we can step directly over.  Is that optimization only effective on 
aarch64?

Anyway, doesn’t matter, this was supposed to be testing the listing of internal 
plans, not our strategies for stepping.  Though it sound like if we want to 
ensure we are stepping directly over we might write a similar test to make sure 
we actually are doing that…

Jim


> On Apr 6, 2020, at 3:42 AM, Pavel Labath  wrote:
> 
> I guess these should go away after 4f644ff9e (which restrict the
> decorator to aarch64). Judging by
> ,
> Jim is going to look into a better solution for that this week.
> 
> pl
> 
> 
> On 06/04/2020 11:50, Jan Kratochvil wrote:
>> Hi,
>> 
>> I get XPASSes now on Fedora 31 x86_64:
>> 
>> http://lab.llvm.org:8014/builders/lldb-x86_64-fedora/builds/7169
>> http://lab.llvm.org:8014/builders/lldb-x86_64-fedora?numbuilds=1000
>> 
>> So maybe to remove the expected failure?
>> 
>> 
>> Jan
>> 
>> 
>> 
>> On Sun, 05 Apr 2020 17:18:54 +0200, Muhammad Omair Javaid via lldb-commits 
>> wrote:
>>> 
>>> Author: Muhammad Omair Javaid
>>> Date: 2020-04-05T20:16:46+05:00
>>> New Revision: b6cd964ac7cb9b55dfcdbe43c5502c2c0f6cbebc
>>> 
>>> URL: 
>>> https://github.com/llvm/llvm-project/commit/b6cd964ac7cb9b55dfcdbe43c5502c2c0f6cbebc
>>> DIFF: 
>>> https://github.com/llvm/llvm-project/commit/b6cd964ac7cb9b55dfcdbe43c5502c2c0f6cbebc.diff
>>> 
>>> LOG: Fix typo in xfail decorator for lldb thread plan list tests
>>> 
>>> Added: 
>>> 
>>> 
>>> Modified: 
>>>lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
>>> 
>>> Removed: 
>>> 
>>> 
>>> 
>>> 
>>> diff  --git 
>>> a/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py 
>>> b/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
>>> index b4ae9107aceb..5214a3f6b0fe 100644
>>> --- a/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
>>> +++ b/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
>>> @@ -17,7 +17,7 @@ class TestThreadPlanCommands(TestBase):
>>> NO_DEBUG_INFO_TESTCASE = True
>>> 
>>> @skipIfWindows
>>> -@expectedFailureAll(oslist=["Linux"])
>>> +@expectedFailureAll(oslist=["linux"])
>>> def test_thread_plan_actions(self):
>>> self.build()
>>> self.main_source_file = lldb.SBFileSpec("main.c")
>>> 
>>> 
>>> 
>>> ___
>>> lldb-commits mailing list
>>> lldb-commits@lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>> 
> 

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

[Lldb-commits] [lldb] 3270748 - The thread plan list test is failing at least on Ubuntu Linux.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-04-03T20:06:11-07:00
New Revision: 327074812707d41f492a0e23940430422a9cd237

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

LOG: The thread plan list test is failing at least on Ubuntu Linux.
Mark it expected fail for now.

The test output shows that the "internal" thread listing isn't showing the
step out plan that we use to step back out of a function we're stepping into.
The internal plan listing code has nothing platform specific in it, so that
isn't the problem.

I am pretty sure the difference is that on MacOS we step into the function and 
then need to
step back out again so we push the internal plan the test is checking for.  But 
on Linux we
are able to step past the function without stepping into it.

So nothing is actually going wrong here, I just need to find a better test case 
where I
can ensure we are going to have to push a private plan.  It's probably better 
to test this
using a custom thread plan, then I can control the state of the plan stack 
better.

That's for Monday...

Added: 


Modified: 
lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py 
b/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
index c301e8cf8441..b4ae9107aceb 100644
--- a/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
+++ b/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
@@ -17,6 +17,7 @@ class TestThreadPlanCommands(TestBase):
 NO_DEBUG_INFO_TESTCASE = True
 
 @skipIfWindows
+@expectedFailureAll(oslist=["Linux"])
 def test_thread_plan_actions(self):
 self.build()
 self.main_source_file = lldb.SBFileSpec("main.c")



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

[Lldb-commits] [lldb] 48ba745 - This test is failing on the Ubuntu bot but the bot log doesn't

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-04-03T18:04:02-07:00
New Revision: 48ba745eacf883080152fe16b5b1305657d001ca

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

LOG: This test is failing on the Ubuntu bot but the bot log doesn't
capture the test stdout, so put the info I need to see in the error
message instead.

Added: 


Modified: 
lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py 
b/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
index 25b184ee406f..c301e8cf8441 100644
--- a/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
+++ b/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
@@ -61,7 +61,7 @@ def check_list_output(self, command, active_plans = [], 
completed_plans = [], di
 fudge = 5
 
 self.assertEqual(num_results, num_active + num_completed + 
num_discarded + fudge,
- "Too many elements in match arrays")
+ "Too many elements in match arrays for: 
\n%s\n"%result.GetOutput())
 
 # Now iterate through the results array and pick out the results.
 result_idx = 0



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

[Lldb-commits] [lldb] 2d658c5 - Disable two new tests on Windows. They are failing but the logs are not helpful.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-04-03T17:14:56-07:00
New Revision: 2d658c56d57c4b355635b2bab38ba97a598c7393

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

LOG: Disable two new tests on Windows.  They are failing but the logs are not 
helpful.

Also turn on the command trace unconditionally for TestThreadPlanCommands.py as 
the
tests for the Ubuntu bot don't seem to run with -t making it hard to see why 
this is
failing remotely.

Added: 


Modified: 

lldb/test/API/functionalities/plugins/python_os_plugin/stepping_plugin_threads/TestOSPluginStepping.py
lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/plugins/python_os_plugin/stepping_plugin_threads/TestOSPluginStepping.py
 
b/lldb/test/API/functionalities/plugins/python_os_plugin/stepping_plugin_threads/TestOSPluginStepping.py
index 5bba48364731..1a625cee5d86 100644
--- 
a/lldb/test/API/functionalities/plugins/python_os_plugin/stepping_plugin_threads/TestOSPluginStepping.py
+++ 
b/lldb/test/API/functionalities/plugins/python_os_plugin/stepping_plugin_threads/TestOSPluginStepping.py
@@ -8,6 +8,7 @@
 
 import os
 import lldb
+from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
 import lldbsuite.test.lldbutil as lldbutil
 
@@ -17,6 +18,7 @@ class TestOSPluginStepping(TestBase):
 mydir = TestBase.compute_mydir(__file__)
 NO_DEBUG_INFO_TESTCASE = True
 
+@skipIfWindows
 def test_python_os_plugin(self):
 """Test that stepping works when the OS Plugin doesn't report all
threads at every stop"""
@@ -24,6 +26,7 @@ def test_python_os_plugin(self):
 self.main_file = lldb.SBFileSpec('main.cpp')
 self.run_python_os_step_missing_thread(False)
 
+@skipIfWindows
 def test_python_os_plugin_prune(self):
 """Test that pruning the unreported PlanStacks works"""
 self.build()

diff  --git 
a/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py 
b/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
index 30fdb218fc2e..25b184ee406f 100644
--- a/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
+++ b/lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
@@ -5,6 +5,7 @@
 
 
 import lldb
+from lldbsuite.test.decorators import *
 import lldbsuite.test.lldbutil as lldbutil
 from lldbsuite.test.lldbtest import *
 
@@ -15,6 +16,7 @@ class TestThreadPlanCommands(TestBase):
 
 NO_DEBUG_INFO_TESTCASE = True
 
+@skipIfWindows
 def test_thread_plan_actions(self):
 self.build()
 self.main_source_file = lldb.SBFileSpec("main.c")
@@ -32,9 +34,8 @@ def check_list_output(self, command, active_plans = [], 
completed_plans = [], di
 num_discarded = len(discarded_plans)
 
 interp.HandleCommand(command, result)
-if self.TraceOn():
-print("Command: %s"%(command))
-print(result.GetOutput())
+print("Command: %s"%(command))
+print(result.GetOutput())
 
 if num_active == 0 and num_completed == 0 and num_discarded == 0:
 self.assertFalse(result.Succeeded(), "command: '%s' succeeded when 
it should have failed: '%s'"%



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

[Lldb-commits] [lldb] e4598dc - Make ThreadPlans use TID and Process, rather than Thread *.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-04-03T14:56:28-07:00
New Revision: e4598dc04a1f582e18b6721ae8ad15cad3ddd48b

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

LOG: Make ThreadPlans use TID and Process, rather than Thread *.

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

Added: 


Modified: 
lldb/include/lldb/Target/ThreadPlan.h
lldb/include/lldb/Target/ThreadPlanPython.h

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp
lldb/source/Target/ThreadPlan.cpp
lldb/source/Target/ThreadPlanBase.cpp
lldb/source/Target/ThreadPlanCallFunction.cpp
lldb/source/Target/ThreadPlanCallFunctionUsingABI.cpp
lldb/source/Target/ThreadPlanCallUserExpression.cpp
lldb/source/Target/ThreadPlanPython.cpp
lldb/source/Target/ThreadPlanRunToAddress.cpp
lldb/source/Target/ThreadPlanStepInRange.cpp
lldb/source/Target/ThreadPlanStepInstruction.cpp
lldb/source/Target/ThreadPlanStepOut.cpp
lldb/source/Target/ThreadPlanStepOverBreakpoint.cpp
lldb/source/Target/ThreadPlanStepOverRange.cpp
lldb/source/Target/ThreadPlanStepRange.cpp
lldb/source/Target/ThreadPlanStepThrough.cpp
lldb/source/Target/ThreadPlanStepUntil.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/ThreadPlan.h 
b/lldb/include/lldb/Target/ThreadPlan.h
index 3e9f7c884137..40c15e3387d7 100644
--- a/lldb/include/lldb/Target/ThreadPlan.h
+++ b/lldb/include/lldb/Target/ThreadPlan.h
@@ -369,13 +369,11 @@ class ThreadPlan : public 
std::enable_shared_from_this,
   ///
   /// \return
   ///   A  pointer to the thread plan's owning thread.
-  Thread &GetThread() { return m_thread; }
+  Thread &GetThread();
 
-  const Thread &GetThread() const { return m_thread; }
+  Target &GetTarget() { return m_process.GetTarget(); }
 
-  Target &GetTarget() { return m_thread.GetProcess()->GetTarget(); }
-
-  const Target &GetTarget() const { return m_thread.GetProcess()->GetTarget(); 
}
+  const Target &GetTarget() const { return m_process.GetTarget(); }
 
   /// Print a description of this thread to the stream \a s.
   /// \a thread.
@@ -464,7 +462,7 @@ class ThreadPlan : public 
std::enable_shared_from_this,
   // Also sets the plans to private and not master plans.  A plan pushed by 
   // another thread plan is never either of the above.
   void PushPlan(lldb::ThreadPlanSP &thread_plan_sp) {
-m_thread.PushPlan(thread_plan_sp);
+GetThread().PushPlan(thread_plan_sp);
 thread_plan_sp->SetPrivate(false);
 thread_plan_sp->SetIsMasterPlan(false);
   }
@@ -497,7 +495,9 @@ class ThreadPlan : public 
std::enable_shared_from_this,
   // original stop reason so that stopping and calling a few functions won't
   // lose the history of the run. This call can be implemented to get you back
   // to the real stop info.
-  virtual lldb::StopInfoSP GetRealStopInfo() { return m_thread.GetStopInfo(); }
+  virtual lldb::StopInfoSP GetRealStopInfo() { 
+return GetThread().GetStopInfo();
+  }
 
   // If the completion of the thread plan stepped out of a function, the return
   // value of the function might have been captured by the thread plan
@@ -560,17 +560,17 @@ class ThreadPlan : public 
std::enable_shared_from_this,
   // This is mostly a formal requirement, it allows us to make the Thread's
   // GetPreviousPlan protected, but only friend ThreadPlan to thread.
 
-  ThreadPlan *GetPreviousPlan() { return m_thread.GetPreviousPlan(this); }
+  ThreadPlan *GetPreviousPlan() { return GetThread().GetPreviousPlan(this); }
 
   // This forwards the private Thread::GetPrivateStopInfo which is generally
   // what ThreadPlan's need to know.
 
   lldb::StopInfoSP GetPrivateStopInfo() {
-return m_thread.GetPrivateStopInfo();
+return GetThread().GetPrivateStopInfo();
   }
 
   void SetStopInfo(lldb::StopInfoSP stop_reason_sp) {
-m_thread.SetStopInfo(stop_reason_sp);
+GetThread().SetStopInfo(stop_reason_sp);
   }
 
   void CachePlanExplainsStop(bool does_explain) {
@@ -586,7 +586,8 @@ class ThreadPlan : public 
std::enable_shared_from_this,
   bool IsUsuallyUnexplainedStopReason(lldb::StopReason);
 
   Status m_status;
-  Thread &m_thread;
+  Process &m_process;
+  lldb::tid_t m_tid;
   Vote m_stop_vote;
   Vote m_run_vote;
   bool m_takes_iteration_count;
@@ -597,6 +598,7 @@ class ThreadPlan : public 
std::enable_shared_from_this,
   // For ThreadPlan only
   static lldb::user_id_t GetNextID();
 
+  Thread *m_thread;
   ThreadPlanKind m_kind;
   std::string m_name;
   std::recursive_mutex m_plan_complete_mutex;

diff  --git a/lldb/include/lldb/Target/ThreadPlanPython.h 
b/lldb/include/lldb/Target/ThreadPlanPython.h
index 99108733b9d5..5b8713c328e2 100644
--- a/lldb/include/lldb/Target/ThreadPlanPython.h
+++ b/lldb/include/lldb

[Lldb-commits] [lldb] 1893065 - Allow the ThreadPlanStackMap to hold the thread plans for threads

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-04-03T14:56:28-07:00
New Revision: 1893065d7bf5c41fbd0dbbee0a39933d3a99806b

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

LOG: Allow the ThreadPlanStackMap to hold the thread plans for threads
that were not reported by the OS plugin.  To facilitate this, move
adding/updating the ThreadPlans for a Thread to the ThreadPlanStackMap.
Also move dumping thread plans there as well.

Added some tests for "thread plan list" and "thread plan discard" since
I didn't seem to have written any originally.

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

Added: 

lldb/test/API/functionalities/plugins/python_os_plugin/stepping_plugin_threads/Makefile

lldb/test/API/functionalities/plugins/python_os_plugin/stepping_plugin_threads/TestOSPluginStepping.py

lldb/test/API/functionalities/plugins/python_os_plugin/stepping_plugin_threads/main.cpp

lldb/test/API/functionalities/plugins/python_os_plugin/stepping_plugin_threads/operating_system.py
lldb/test/API/functionalities/thread_plan/Makefile
lldb/test/API/functionalities/thread_plan/TestThreadPlanCommands.py
lldb/test/API/functionalities/thread_plan/main.c

Modified: 
lldb/include/lldb/Target/Process.h
lldb/include/lldb/Target/Target.h
lldb/include/lldb/Target/Thread.h
lldb/include/lldb/Target/ThreadPlan.h
lldb/include/lldb/Target/ThreadPlanStack.h
lldb/source/Commands/CommandObjectThread.cpp
lldb/source/Commands/Options.td
lldb/source/Target/Process.cpp
lldb/source/Target/Target.cpp
lldb/source/Target/TargetProperties.td
lldb/source/Target/Thread.cpp
lldb/source/Target/ThreadList.cpp
lldb/source/Target/ThreadPlan.cpp
lldb/source/Target/ThreadPlanStack.cpp
lldb/source/Target/ThreadPlanStepOut.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index 02987f9b50b7..82c302c08e11 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -2198,19 +2198,75 @@ class Process : public 
std::enable_shared_from_this,
   }
 
   void SetDynamicCheckers(DynamicCheckerFunctions *dynamic_checkers);
-  
+
+/// Prune ThreadPlanStacks for unreported threads.
+///
+/// \param[in] tid
+/// The tid whose Plan Stack we are seeking to prune.
+///
+/// \return
+/// \b true if the TID is found or \b false if not.
+bool PruneThreadPlansForTID(lldb::tid_t tid);
+
+/// Prune ThreadPlanStacks for all unreported threads.
+void PruneThreadPlans();
+
   /// Find the thread plan stack associated with thread with \a tid.
   ///
   /// \param[in] tid
-  /// The tid whose Plan Stack we are seeking..
+  /// The tid whose Plan Stack we are seeking.
   ///
   /// \return
   /// Returns a ThreadPlan if the TID is found or nullptr if not.
   ThreadPlanStack *FindThreadPlans(lldb::tid_t tid);
-  
-  void AddThreadPlansForThread(Thread &thread);
-  
-  void RemoveThreadPlansForTID(lldb::tid_t tid);
+
+  /// Dump the thread plans associated with thread with \a tid.
+  ///
+  /// \param[in/out] strm
+  /// The stream to which to dump the output
+  ///
+  /// \param[in] tid
+  /// The tid whose Plan Stack we are dumping
+  ///
+  /// \param[in] desc_level
+  /// How much detail to dump
+  ///
+  /// \param[in] internal
+  /// If \b true dump all plans, if false only user initiated plans
+  ///
+  /// \param[in] condense_trivial
+  /// If true, only dump a header if the plan stack is just the base plan.
+  ///
+  /// \param[in] skip_unreported_plans
+  /// If true, only dump a plan if it is currently backed by an
+  /// lldb_private::Thread *.
+  ///
+  /// \return
+  /// Returns \b true if TID was found, \b false otherwise
+  bool DumpThreadPlansForTID(Stream &strm, lldb::tid_t tid,
+ lldb::DescriptionLevel desc_level, bool internal,
+ bool condense_trivial, bool 
skip_unreported_plans);
+
+  /// Dump all the thread plans for this process.
+  ///
+  /// \param[in/out] strm
+  /// The stream to which to dump the output
+  ///
+  /// \param[in] desc_level
+  /// How much detail to dump
+  ///
+  /// \param[in] internal
+  /// If \b true dump all plans, if false only user initiated plans
+  ///
+  /// \param[in] condense_trivial
+  /// If true, only dump a header if the plan stack is just the base plan.
+  ///
+  /// \param[in] skip_unreported_plans
+  /// If true, skip printing all thread plan stacks that don't currently
+  /// have a backing lldb_private::Thread *.
+  void DumpThreadPlans(Stream &strm, lldb::DescriptionLevel desc_level,
+   bool internal, bool condense_trivial,
+   bool skip_unreported_plans);
 
   /// 

[Lldb-commits] [lldb] 61e8e68 - Move thread plan stacks into the Process, indexed by TID.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-04-03T14:56:28-07:00
New Revision: 61e8e6882de7c89933d3cc4c4d44719679e4b4f0

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

LOG: Move thread plan stacks into the Process, indexed by TID.

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

Added: 
lldb/include/lldb/Target/ThreadPlanStack.h
lldb/source/Target/ThreadPlanStack.cpp

Modified: 
lldb/include/lldb/Target/Process.h
lldb/include/lldb/Target/Thread.h
lldb/include/lldb/Target/ThreadPlan.h
lldb/source/Target/CMakeLists.txt
lldb/source/Target/Process.cpp
lldb/source/Target/Thread.cpp
lldb/source/Target/ThreadList.cpp
lldb/source/Target/ThreadPlan.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index 87f61c66bb41..02987f9b50b7 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -37,6 +37,7 @@
 #include "lldb/Target/Memory.h"
 #include "lldb/Target/QueueList.h"
 #include "lldb/Target/ThreadList.h"
+#include "lldb/Target/ThreadPlanStack.h"
 #include "lldb/Utility/ArchSpec.h"
 #include "lldb/Utility/Broadcaster.h"
 #include "lldb/Utility/Event.h"
@@ -2197,6 +2198,19 @@ class Process : public 
std::enable_shared_from_this,
   }
 
   void SetDynamicCheckers(DynamicCheckerFunctions *dynamic_checkers);
+  
+  /// Find the thread plan stack associated with thread with \a tid.
+  ///
+  /// \param[in] tid
+  /// The tid whose Plan Stack we are seeking..
+  ///
+  /// \return
+  /// Returns a ThreadPlan if the TID is found or nullptr if not.
+  ThreadPlanStack *FindThreadPlans(lldb::tid_t tid);
+  
+  void AddThreadPlansForThread(Thread &thread);
+  
+  void RemoveThreadPlansForTID(lldb::tid_t tid);
 
   /// Call this to set the lldb in the mode where it breaks on new thread
   /// creations, and then auto-restarts.  This is useful when you are trying
@@ -2533,7 +2547,7 @@ class Process : public 
std::enable_shared_from_this,
 virtual EventActionResult HandleBeingInterrupted() = 0;
 virtual const char *GetExitString() = 0;
 void RequestResume() { m_process->m_resume_requested = true; }
-
+
   protected:
 Process *m_process;
   };
@@ -2667,6 +2681,10 @@ class Process : public 
std::enable_shared_from_this,
 ///see them. This is usually the same as
   ///< m_thread_list_real, but might be 
diff erent if there is an OS plug-in
   ///creating memory threads
+  ThreadPlanStackMap m_thread_plans; ///< This is the list of thread plans for
+ /// threads in m_thread_list, as well as
+ /// threads we knew existed, but haven't
+ /// determined that they have died yet.
   ThreadList m_extended_thread_list; ///< Owner for extended threads that may 
be
  ///generated, cleared on natural stops
   uint32_t m_extended_thread_stop_id; ///< The natural stop id when

diff  --git a/lldb/include/lldb/Target/Thread.h 
b/lldb/include/lldb/Target/Thread.h
index b0bc1b29eb78..dda303ff3c46 100644
--- a/lldb/include/lldb/Target/Thread.h
+++ b/lldb/include/lldb/Target/Thread.h
@@ -28,6 +28,8 @@
 
 namespace lldb_private {
 
+class ThreadPlanStack;
+
 class ThreadProperties : public Properties {
 public:
   ThreadProperties(bool is_global);
@@ -119,7 +121,7 @@ class Thread : public std::enable_shared_from_this,
// bit of data.
 lldb::StopInfoSP stop_info_sp; // You have to restore the stop info or you
// might continue with the wrong signals.
-std::vector m_completed_plan_stack;
+size_t m_completed_plan_checkpoint;
 lldb::RegisterCheckpointSP
 register_backup_sp; // You need to restore the registers, of course...
 uint32_t current_inlined_depth;
@@ -912,7 +914,7 @@ class Thread : public std::enable_shared_from_this,
   ///
   /// \return
   /// A pointer to the next executed plan.
-  ThreadPlan *GetCurrentPlan();
+  ThreadPlan *GetCurrentPlan() const;
 
   /// Unwinds the thread stack for the innermost expression plan currently
   /// on the thread plan stack.
@@ -927,14 +929,14 @@ class Thread : public 
std::enable_shared_from_this,
   ///
   /// \return
   /// A pointer to the last completed plan.
-  lldb::ThreadPlanSP GetCompletedPlan();
+  lldb::ThreadPlanSP GetCompletedPlan() const;
 
   /// Gets the outer-most return value from the completed plans
   ///
   /// \return
   /// A ValueObjectSP, either empty if there is no return value,
   /// or containing the return value.
-  lldb::ValueObjectSP GetReturnValueObject();
+  lldb::ValueObjectSP GetReturnValueObject() const;
 
   /// Gets the outer

[Lldb-commits] [lldb] 2c1c57a - Make ThreadPlanTracers use TID & Process rather than Thread *.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-04-03T14:56:28-07:00
New Revision: 2c1c57a1df8187870df114af666bacbd413699f7

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

LOG: Make ThreadPlanTracers use TID & Process rather than Thread *.

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

Added: 


Modified: 
lldb/include/lldb/Target/ThreadPlanTracer.h
lldb/source/Target/ThreadPlanTracer.cpp

Removed: 




diff  --git a/lldb/include/lldb/Target/ThreadPlanTracer.h 
b/lldb/include/lldb/Target/ThreadPlanTracer.h
index 9a0bebf560a5..677a2c0dd93c 100644
--- a/lldb/include/lldb/Target/ThreadPlanTracer.h
+++ b/lldb/include/lldb/Target/ThreadPlanTracer.h
@@ -57,9 +57,12 @@ class ThreadPlanTracer {
   }
 
   bool SingleStepEnabled() { return m_single_step; }
+  
+  Thread &GetThread();
 
 protected:
-  Thread &m_thread;
+  Process &m_process;
+  lldb::tid_t m_tid;
 
   Stream *GetLogStream();
 
@@ -71,6 +74,7 @@ class ThreadPlanTracer {
   bool m_single_step;
   bool m_enabled;
   lldb::StreamSP m_stream_sp;
+  Thread *m_thread;
 };
 
 class ThreadPlanAssemblyTracer : public ThreadPlanTracer {

diff  --git a/lldb/source/Target/ThreadPlanTracer.cpp 
b/lldb/source/Target/ThreadPlanTracer.cpp
index 0ca520c5f9ee..c00415f3c1ee 100644
--- a/lldb/source/Target/ThreadPlanTracer.cpp
+++ b/lldb/source/Target/ThreadPlanTracer.cpp
@@ -34,23 +34,32 @@ using namespace lldb_private;
 #pragma mark ThreadPlanTracer
 
 ThreadPlanTracer::ThreadPlanTracer(Thread &thread, lldb::StreamSP &stream_sp)
-: m_thread(thread), m_single_step(true), m_enabled(false),
-  m_stream_sp(stream_sp) {}
+: m_process(*thread.GetProcess().get()), m_tid(thread.GetID()),
+  m_single_step(true), m_enabled(false), m_stream_sp(stream_sp) {}
 
 ThreadPlanTracer::ThreadPlanTracer(Thread &thread)
-: m_thread(thread), m_single_step(true), m_enabled(false), m_stream_sp() {}
+: m_process(*thread.GetProcess().get()), m_tid(thread.GetID()),
+  m_single_step(true), m_enabled(false), m_stream_sp() {}
 
 Stream *ThreadPlanTracer::GetLogStream() {
   if (m_stream_sp)
 return m_stream_sp.get();
   else {
-TargetSP target_sp(m_thread.CalculateTarget());
+TargetSP target_sp(GetThread().CalculateTarget());
 if (target_sp)
   return &(target_sp->GetDebugger().GetOutputStream());
   }
   return nullptr;
 }
 
+Thread &ThreadPlanTracer::GetThread() {
+  if (m_thread)
+return *m_thread;
+
+  ThreadSP thread_sp = m_process.GetThreadList().FindThreadByID(m_tid);
+  m_thread = thread_sp.get();
+  return *m_thread;
+}
 void ThreadPlanTracer::Log() {
   SymbolContext sc;
   bool show_frame_index = false;
@@ -58,8 +67,8 @@ void ThreadPlanTracer::Log() {
 
   Stream *stream = GetLogStream();
   if (stream) {
-m_thread.GetStackFrameAtIndex(0)->Dump(stream, show_frame_index,
-   show_fullpaths);
+GetThread().GetStackFrameAtIndex(0)->Dump(stream, show_frame_index,
+  show_fullpaths);
 stream->Printf("\n");
 stream->Flush();
   }
@@ -67,7 +76,7 @@ void ThreadPlanTracer::Log() {
 
 bool ThreadPlanTracer::TracerExplainsStop() {
   if (m_enabled && m_single_step) {
-lldb::StopInfoSP stop_info = m_thread.GetStopInfo();
+lldb::StopInfoSP stop_info = GetThread().GetStopInfo();
 return (stop_info->GetStopReason() == eStopReasonTrace);
   } else
 return false;
@@ -87,13 +96,13 @@ ThreadPlanAssemblyTracer::ThreadPlanAssemblyTracer(Thread 
&thread)
 Disassembler *ThreadPlanAssemblyTracer::GetDisassembler() {
   if (!m_disassembler_sp)
 m_disassembler_sp = Disassembler::FindPlugin(
-m_thread.GetProcess()->GetTarget().GetArchitecture(), nullptr, 
nullptr);
+m_process.GetTarget().GetArchitecture(), nullptr, nullptr);
   return m_disassembler_sp.get();
 }
 
 TypeFromUser ThreadPlanAssemblyTracer::GetIntPointerType() {
   if (!m_intptr_type.IsValid()) {
-if (auto target_sp = m_thread.CalculateTarget()) {
+if (auto target_sp = m_process.CalculateTarget()) {
   auto type_system_or_err =
   target_sp->GetScratchTypeSystemForLanguage(eLanguageTypeC);
   if (auto err = type_system_or_err.takeError()) {
@@ -125,29 +134,27 @@ void ThreadPlanAssemblyTracer::Log() {
   if (!stream)
 return;
 
-  RegisterContext *reg_ctx = m_thread.GetRegisterContext().get();
+  RegisterContext *reg_ctx = GetThread().GetRegisterContext().get();
 
   lldb::addr_t pc = reg_ctx->GetPC();
-  ProcessSP process_sp(m_thread.GetProcess());
   Address pc_addr;
   bool addr_valid = false;
   uint8_t buffer[16] = {0}; // Must be big enough for any single instruction
-  addr_valid = process_sp->GetTarget().GetSectionLoadList().ResolveLoadAddress(
+  addr_valid = m_process.GetTarget().GetSectionLoadList().

[Lldb-commits] [lldb] 67d67eb - Internal expressions shouldn't increment the result variable numbering.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-03-23T13:30:37-07:00
New Revision: 67d67ebe8f2535c5de75c62820f7713f87d07307

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

LOG: Internal expressions shouldn't increment the result variable numbering.

There an option: EvaluateExpressionOptions::SetResultIsInternal to indicate
whether the result number should be returned to the pool or not.  It
got broken when the PersistentExpressionState was refactored.

This fixes the issue and provides a test of the behavior.

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

Added: 
lldb/test/API/commands/expression/result_numbering/Makefile
lldb/test/API/commands/expression/result_numbering/TestResultNumbering.py
lldb/test/API/commands/expression/result_numbering/main.c

Modified: 
lldb/include/lldb/Expression/ExpressionVariable.h
lldb/include/lldb/Target/Target.h
lldb/source/Core/ValueObject.cpp
lldb/source/Expression/ExpressionVariable.cpp
lldb/source/Expression/Materializer.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangPersistentVariables.cpp
lldb/source/Plugins/ExpressionParser/Clang/ClangPersistentVariables.h
lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
lldb/source/Target/ABI.cpp

Removed: 




diff  --git a/lldb/include/lldb/Expression/ExpressionVariable.h 
b/lldb/include/lldb/Expression/ExpressionVariable.h
index c523176e003f..60062d212bad 100644
--- a/lldb/include/lldb/Expression/ExpressionVariable.h
+++ b/lldb/include/lldb/Expression/ExpressionVariable.h
@@ -221,11 +221,7 @@ class PersistentExpressionState : public 
ExpressionVariableList {
uint32_t addr_byte_size) = 0;
 
   /// Return a new persistent variable name with the specified prefix.
-  ConstString GetNextPersistentVariableName(Target &target,
-llvm::StringRef prefix);
-
-  virtual llvm::StringRef
-  GetPersistentVariablePrefix(bool is_error = false) const = 0;
+  virtual ConstString GetNextPersistentVariableName(bool is_error = false) = 0;
 
   virtual void
   RemovePersistentVariable(lldb::ExpressionVariableSP variable) = 0;
@@ -237,6 +233,10 @@ class PersistentExpressionState : public 
ExpressionVariableList {
 
   void RegisterExecutionUnit(lldb::IRExecutionUnitSP &execution_unit_sp);
 
+protected:
+  virtual llvm::StringRef
+  GetPersistentVariablePrefix(bool is_error = false) const = 0;
+
 private:
   LLVMCastKind m_kind;
 

diff  --git a/lldb/include/lldb/Target/Target.h 
b/lldb/include/lldb/Target/Target.h
index 77cda4998192..cc74fe0f3d74 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -1100,11 +1100,6 @@ class Target : public 
std::enable_shared_from_this,
 
   lldb::ExpressionVariableSP GetPersistentVariable(ConstString name);
 
-  /// Return the next available number for numbered persistent variables.
-  unsigned GetNextPersistentVariableIndex() {
-return m_next_persistent_variable_index++;
-  }
-
   lldb::addr_t GetPersistentSymbol(ConstString name);
 
   /// This method will return the address of the starting function for

diff  --git a/lldb/source/Core/ValueObject.cpp 
b/lldb/source/Core/ValueObject.cpp
index e1d0ca941108..4c9c44ea15f4 100644
--- a/lldb/source/Core/ValueObject.cpp
+++ b/lldb/source/Core/ValueObject.cpp
@@ -3270,9 +3270,7 @@ ValueObjectSP ValueObject::Persist() {
   if (!persistent_state)
 return nullptr;
 
-  auto prefix = persistent_state->GetPersistentVariablePrefix();
-  ConstString name =
-  persistent_state->GetNextPersistentVariableName(*target_sp, prefix);
+  ConstString name = persistent_state->GetNextPersistentVariableName();
 
   ValueObjectSP const_result_sp =
   ValueObjectConstResult::Create(target_sp.get(), GetValue(), name);

diff  --git a/lldb/source/Expression/ExpressionVariable.cpp 
b/lldb/source/Expression/ExpressionVariable.cpp
index 7c27c0f249ec..d95f0745cf4b 100644
--- a/lldb/source/Expression/ExpressionVariable.cpp
+++ b/lldb/source/Expression/ExpressionVariable.cpp
@@ -76,13 +76,3 @@ void PersistentExpressionState::RegisterExecutionUnit(
 }
   }
 }
-
-ConstString PersistentExpressionState::GetNextPersistentVariableName(
-Target &target, llvm::StringRef Prefix) {
-  llvm::SmallString<64> name;
-  {
-llvm::raw_svector_ostream os(name);
-os << Prefix << target.GetNextPersistentVariableIndex();
-  }
-  return ConstString(name);
-}

diff  --git a/lldb/source/Expression/Materializer.cpp 
b/lldb/source/Expression/Materializer.cpp
index 33c061effca4..8e96891257e4 100644
--- a/lldb/source/Expression/Materializer.cpp
+++ b/lldb/source/Expression/Materializer.cpp
@@ -881,11 +881,9 @@ class EntityResultVariable : public Materializer::Entity {
   return;
 }
 
-ConstStrin

Re: [Lldb-commits] [lldb] 6385c2a - [AppleObjCRuntimeV2] Force lazily allocated class names to be resolved.

[Jim Ingham via lldb-commits]

Yes, I’m working on a fix.

Can you use regular expressions or globs in FileCheck matching?   It means if 
you ever add a test that makes an expression above this test in the file, you 
have to go renumber everything.  That's kind of annoying even if the numbering 
was still working, and you aren’t testing the expression results numbering here 
anyway…

Jim


> On Mar 20, 2020, at 1:44 PM, Davidino Italiano via lldb-commits 
>  wrote:
> 
> 
> 
>> On Mar 20, 2020, at 1:43 PM, Davide Italiano via lldb-commits 
>>  wrote:
>> 
>> 
>> Author: Davide Italiano
>> Date: 2020-03-20T13:43:08-07:00
>> New Revision: 6385c2ab8ff8304eafa822012c40934690bde124
>> 
>> URL: 
>> https://github.com/llvm/llvm-project/commit/6385c2ab8ff8304eafa822012c40934690bde124
>> DIFF: 
>> https://github.com/llvm/llvm-project/commit/6385c2ab8ff8304eafa822012c40934690bde124.diff
>> 
>> LOG: [AppleObjCRuntimeV2] Force lazily allocated class names to be resolved.
>> 
>> Fixes a couple of tests on new versions of the Obj-C runtime.
>> 
>> Added: 
>> 
>> 
>> Modified: 
>>   
>> lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
>>   lldb/test/Shell/ExecControl/StopHook/stop-hook.test
>> 
>> Removed: 
>> 
>> 
>> 
>> 
>> diff  --git 
>> a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
>>  
>> b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
>> index 9fea9a217dce..4a07c792eebb 100644
>> --- 
>> a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
>> +++ 
>> b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
>> @@ -1175,6 +1175,28 @@ AppleObjCRuntimeV2::GetClassDescriptorFromISA(ObjCISA 
>> isa) {
>>  return class_descriptor_sp;
>> }
>> 
>> +static std::pair ObjCGetClassNameRaw(
>> +  AppleObjCRuntime::ObjCISA isa,
>> +  Process *process) {
>> +  StreamString expr_string;
>> +  std::string input = std::to_string(isa);
>> +  expr_string.Printf("(const char *)objc_debug_class_getNameRaw(%s)",
>> + input.c_str());
>> +
>> +  ValueObjectSP result_sp;
>> +  EvaluateExpressionOptions eval_options;
>> +  eval_options.SetLanguage(lldb::eLanguageTypeObjC);
>> +  eval_options.SetResultIsInternal(true);
>> +  eval_options.SetGenerateDebugInfo(true);
>> +  eval_options.SetTimeout(process->GetUtilityExpressionTimeout());
>> +  auto eval_result = process->GetTarget().EvaluateExpression(
>> +  expr_string.GetData(),
>> +  
>> process->GetThreadList().GetSelectedThread()->GetSelectedFrame().get(),
>> +  result_sp, eval_options);
>> +  ConstString type_name(result_sp->GetSummaryAsCString());
>> +  return std::make_pair(eval_result == eExpressionCompleted, type_name);
>> +}
>> +
>> ObjCLanguageRuntime::ClassDescriptorSP
>> AppleObjCRuntimeV2::GetClassDescriptor(ValueObject &valobj) {
>>  ClassDescriptorSP objc_class_sp;
>> @@ -1210,7 +1232,10 @@ AppleObjCRuntimeV2::GetClassDescriptor(ValueObject 
>> &valobj) {
>>return objc_class_sp;
>> 
>>  objc_class_sp = GetClassDescriptorFromISA(isa);
>> -  if (isa && !objc_class_sp) {
>> +
>> +  if (objc_class_sp)
>> +return objc_class_sp;
>> +  else {
>>Log *log(GetLogIfAllCategoriesSet(LIBLLDB_LOG_PROCESS |
>>  LIBLLDB_LOG_TYPES));
>>LLDB_LOGF(log,
>> @@ -1219,6 +1244,13 @@ AppleObjCRuntimeV2::GetClassDescriptor(ValueObject 
>> &valobj) {
>>  "not in class descriptor cache 0x%" PRIx64,
>>  isa_pointer, isa);
>>  }
>> +
>> +  ClassDescriptorSP descriptor_sp(new ClassDescriptorV2(*this, isa, 
>> nullptr));
>> +  auto resolved = ObjCGetClassNameRaw(isa, process);
>> +  if (resolved.first == true) {
>> +AddClass(isa, descriptor_sp, resolved.second.AsCString());
>> +objc_class_sp = descriptor_sp;
>> +  }
>>  return objc_class_sp;
>> }
>> 
>> 
>> diff  --git a/lldb/test/Shell/ExecControl/StopHook/stop-hook.test 
>> b/lldb/test/Shell/ExecControl/StopHook/stop-hook.test
>> index a06de6634ea1..7e5b37b63854 100644
>> --- a/lldb/test/Shell/ExecControl/StopHook/stop-hook.test
>> +++ b/lldb/test/Shell/ExecControl/StopHook/stop-hook.test
>> @@ -51,7 +51,7 @@ run
>> thread step-over
>> # Stepping inside of the stop hook range
>> # CHECK: (lldb) thread step-over
>> -# CHECK-NEXT: (void *) $1 = 0x
>> +# CHECK-NEXT: (void *) $2 = 0x
>> # CHECK: ->{{.*}} // We should stop here after stepping.
> 
> This is an unfortunate side effect of SetResultInternal not working in the 
> expression parser.
> Jim Ingham is fixing this, to the best of my knowledge.
> 
> —
> Davide
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

___
lldb-commits mailing list
lldb-commits@lists

Re: [Lldb-commits] [lldb] e98ef0a - [lldb] Fix several LLDB_LOGs with wrong indices in ClangASTSource.cpp

[Jim Ingham via lldb-commits]

We should really have a low-frequency bot that just runs the whole testsuite 
with all the logs turned on and make sure that doesn't crash...

Jim


> On Mar 4, 2020, at 10:56 AM, Raphael “Teemperor” Isemann via lldb-commits 
>  wrote:
> 
> Yeah this whole thing is a disaster and it’s puzzling that we don’t test the 
> whole logging but instead just crash on the end user machine. I’m currently 
> writing a test that gives all this code at least coverage and then I guess we 
> have to fix all of these bugs.
> 
>> On Mar 4, 2020, at 10:53 AM, Shafik Yaghmour  wrote:
>> 
>> This is a lot of errors, did it the index use to start at one before? 
>> 
>> There is a type below, noted inline
>> 
>>> On Mar 4, 2020, at 10:33 AM, Raphael Isemann via lldb-commits 
>>>  wrote:
>>> 
>>> 
>>> Author: Raphael Isemann
>>> Date: 2020-03-04T10:32:50-08:00
>>> New Revision: e98ef0af2c725f12dc60556a039e947ddeeb9f42
>>> 
>>> URL: 
>>> https://github.com/llvm/llvm-project/commit/e98ef0af2c725f12dc60556a039e947ddeeb9f42
>>> DIFF: 
>>> https://github.com/llvm/llvm-project/commit/e98ef0af2c725f12dc60556a039e947ddeeb9f42.diff
>>> 
>>> LOG: [lldb] Fix several LLDB_LOGs with wrong indices in ClangASTSource.cpp
>>> 
>>> Added: 
>>> 
>>> 
>>> Modified: 
>>>   lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
>>> 
>>> Removed: 
>>> 
>>> 
>>> 
>>> 
>>> diff  --git a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp 
>>> b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
>>> index 4d98d9cbdda3..6a8c7bd46559 100644
>>> --- a/lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
>>> +++ b/lldb/source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
>>> @@ -190,8 +190,8 @@ void ClangASTSource::CompleteType(TagDecl *tag_decl) {
>>> 
>>>  if (log) {
>>>LLDB_LOG(log,
>>> - "CompleteTagDecl on (ASTContext*){1} Completing "
>>> - "(TagDecl*){2} named {3}",
>>> + "CompleteTagDecl on (ASTContext*){0} Completing "
>>> + "(TagDecl*){1} named {2}",
>>> m_clang_ast_context->getDisplayName(), tag_decl,
>>> tag_decl->getName());
>>> 
>>> @@ -220,7 +220,7 @@ void ClangASTSource::CompleteType(TagDecl *tag_decl) {
>>>  ClangASTImporter::NamespaceMapSP namespace_map =
>>>  m_ast_importer_sp->GetNamespaceMap(namespace_context);
>>> 
>>> -  LLDB_LOGV(log, "  CTD Inspecting namespace map{1} ({2} entries)",
>>> +  LLDB_LOGV(log, "  CTD Inspecting namespace map{0} ({1} entries)",
>>>namespace_map.get(), namespace_map->size());
>>> 
>>>  if (!namespace_map)
>>> @@ -229,7 +229,7 @@ void ClangASTSource::CompleteType(TagDecl *tag_decl) {
>>>  for (ClangASTImporter::NamespaceMap::iterator i = 
>>> namespace_map->begin(),
>>>e = namespace_map->end();
>>>   i != e && !found; ++i) {
>>> -LLDB_LOG(log, "  CTD Searching namespace {1} in module {2}",
>>> +LLDB_LOG(log, "  CTD Searching namespace {0} in module {1}",
>>> i->second.GetName(), i->first->GetFileSpec().GetFilename());
>>> 
>>>TypeList types;
>>> @@ -478,12 +478,12 @@ void ClangASTSource::FindExternalLexicalDecls(
>>>std::string ast_dump = ClangUtil::DumpDecl(decl);
>>>if (const NamedDecl *context_named_decl =
>>>dyn_cast(context_decl))
>>> -  LLDB_LOG(log, "  FELD Adding [to {1}Decl {2}] lexical {3}Decl 
>>> {4}",
>>> +  LLDB_LOG(log, "  FELD Adding [to {0}Decl {1}] lexical {2}Decl 
>>> 34}”,
>> 
>> 
>> Typo should be {3} not 34}
>> 
>> 
>>>   context_named_decl->getDeclKindName(),
>>>   context_named_decl->getName(), decl->getDeclKindName(),
>>>   ast_dump);
>>>else
>>> -  LLDB_LOG(log, "  FELD Adding lexical {1}Decl {2}",
>>> +  LLDB_LOG(log, "  FELD Adding lexical {0}Decl {1}",
>>>   decl->getDeclKindName(), ast_dump);
>>>  }
>>> 
>>> @@ -527,19 +527,19 @@ void 
>>> ClangASTSource::FindExternalVisibleDecls(NameSearchContext &context) {
>>>if (!context.m_decl_context)
>>>  LLDB_LOG(log,
>>>   "ClangASTSource::FindExternalVisibleDecls on "
>>> -   "(ASTContext*){1} '{2}' for '{3}' in a NULL DeclContext",
>>> +   "(ASTContext*){0} '{1}' for '{2}' in a NULL DeclContext",
>>>   m_ast_context, m_clang_ast_context->getDisplayName(), name);
>>>else if (const NamedDecl *context_named_decl =
>>> dyn_cast(context.m_decl_context))
>>>  LLDB_LOG(log,
>>>   "ClangASTSource::FindExternalVisibleDecls on "
>>> -   "(ASTContext*){1} '{2}' for '{3}' in '{4}'",
>>> +   "(ASTContext*){0} '{1}' for '{2}' in '{3}'",
>>>   m_ast_context, m_clang_ast_context->getDisplayName(), name,
>>>   context_n

[Lldb-commits] [lldb] 3cd13c4 - Fix a race between lldb's packet timeout and the profile thread's usleep.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-02-25T11:17:08-08:00
New Revision: 3cd13c4624b5900c884b691b72d0ca053433f6fe

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

LOG: Fix a race between lldb's packet timeout and the profile thread's usleep.

The debugserver profile thread used to suspend itself between samples with
a usleep.  When you detach or kill, MachProcess::Clear would delay replying
to the incoming packet until pthread_join of the profile thread returned.
If you are unlucky or the suspend delay is long, it could take longer than
the packet timeout for pthread_join to return.  Then you would get an error
about detach not succeeding from lldb - even though in fact the detach was
successful...

I replaced the usleep with PThreadEvents entity.  Then we just call a timed
WaitForEventBits, and when debugserver wants to stop the profile thread, it
can set the event bit, and the sleep will exit immediately.

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

Added: 
lldb/test/API/macosx/profile_vrs_detach/Makefile
lldb/test/API/macosx/profile_vrs_detach/TestDetachVrsProfile.py
lldb/test/API/macosx/profile_vrs_detach/main.c

Modified: 
lldb/tools/debugserver/source/MacOSX/MachProcess.h
lldb/tools/debugserver/source/MacOSX/MachProcess.mm

Removed: 




diff  --git a/lldb/test/API/macosx/profile_vrs_detach/Makefile 
b/lldb/test/API/macosx/profile_vrs_detach/Makefile
new file mode 100644
index ..695335e068c0
--- /dev/null
+++ b/lldb/test/API/macosx/profile_vrs_detach/Makefile
@@ -0,0 +1,4 @@
+C_SOURCES := main.c
+CFLAGS_EXTRAS := -std=c99
+
+include Makefile.rules

diff  --git a/lldb/test/API/macosx/profile_vrs_detach/TestDetachVrsProfile.py 
b/lldb/test/API/macosx/profile_vrs_detach/TestDetachVrsProfile.py
new file mode 100644
index ..31a9bce78cdc
--- /dev/null
+++ b/lldb/test/API/macosx/profile_vrs_detach/TestDetachVrsProfile.py
@@ -0,0 +1,76 @@
+"""
+debugserver used to block replying to the 'D' packet
+till it had joined the profiling thread.  If the profiling interval
+was too long, that would mean it would take longer than the packet
+timeout to reply, and the detach would time out.  Make sure that doesn't
+happen. 
+"""
+
+
+
+import lldb
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+import os
+import signal
+
+class TestDetachVrsProfile(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+NO_DEBUG_INFO_TESTCASE = True
+
+@skipUnlessDarwin
+@skipIfOutOfTreeDebugserver
+def test_profile_and_detach(self):
+"""There can be many tests in a test case - describe this test here."""
+self.build()
+self.main_source_file = lldb.SBFileSpec("main.c")
+self.do_profile_and_detach()
+
+def do_profile_and_detach(self):
+(target, process, thread, bkpt) = 
lldbutil.run_to_source_breakpoint(self,
+   "Set a breakpoint here", 
self.main_source_file)
+
+interp = self.dbg.GetCommandInterpreter()
+result = lldb.SBCommandReturnObject()
+
+# First make sure we are getting async data.  Set a short interval, 
continue a bit and check:
+interp.HandleCommand("process plugin packet send 
'QSetEnableAsyncProfiling;enable:1;interval_usec:50;scan_type=0x5;'", 
result)
+self.assertTrue(result.Succeeded(), "process packet send failed: 
%s"%(result.GetError()))
+
+# Run a bit to give us a change to collect profile data:
+bkpt.SetIgnoreCount(1)
+threads = lldbutil.continue_to_breakpoint(process, bkpt)
+self.assertEqual(len(threads), 1, "Hit our breakpoint again.")
+str = process.GetAsyncProfileData(1000)
+self.assertTrue(len(str) > 0, "Got some profile data")
+
+# Now make the profiling interval very long and try to detach.
+interp.HandleCommand("process plugin packet send 
'QSetEnableAsyncProfiling;enable:1;interval_usec:1000;scan_type=0x5;'", 
result)
+self.assertTrue(result.Succeeded(), "process packet send failed: 
%s"%(result.GetError()))
+self.dbg.SetAsync(True)
+listener = self.dbg.GetListener()
+
+# We don't want to hit our breakpoint anymore.
+bkpt.SetEnabled(False)
+
+# Record our process pid so we can kill it since we are going to 
detach...
+self.pid = process.GetProcessID()
+def cleanup():
+self.dbg.SetAsync(False)
+os.kill(self.pid, signal.SIGKILL)
+self.addTearDownHook(cleanup)
+
+process.Continue()
+
+event = lldb.SBEvent()
+success = listener.WaitForEventForBroadcaster(0, 
process.GetBroadcaster(), event)
+self.assertTrue(success, "G

Re: [Lldb-commits] [PATCH] D75004: Fix a race between lldb's packet timeout and killing the profile thread

[Jim Ingham via lldb-commits]

I don’t understand your suggestion.  The point of this change was to get the 
profile loop to exit without waiting the full sleep time.  That time is 
generally pretty long (1 second or thereabouts) and so if you have the main 
debugserver thread wait on the profile thread’s timeout before replying to the 
detach packet, then lldb might have already timed out waiting for the packet 
reply by the time it does so.

You could also fix this by not doing the pthread_join but instead have the 
detaching finish independently and then let the profile thread exit after the 
fact, but that seems like asking for trouble.  Or you could reply to the detach 
right away, and then wait on the profile thread to exit as debugserver is going 
down.  But the current code is not at all set up to do that.  

Anyway, this solution has the benefit of being exactly what you want to have 
happen - the profile thread stops its wait sleep immediately when told to exit. 
 And it relies on well tested mechanisms, and doesn’t seem terribly intrusive.

BTW, I thought about doing the time calculation outside the profile thread 
loop, but I couldn’t see anything that said you have to stop and restart the 
profile loop when you change the timeout.  So it didn’t seem safe to only 
calculate the timeout once.  However, if we want to require that you stop and 
start the profile thread when you change its wait interval it would be fine to 
do that.

Jim


> On Feb 21, 2020, at 6:27 PM, Greg Clayton via Phabricator 
>  wrote:
> 
> clayborg added a comment.
> 
> Lots of change for something that might be fixed much easier:
> 
> Alt way: Why not just set m_profile_enabled to false in StopProfileThread() 
> and let loop exit on next iteration? Code changes would be much smaller. All 
> comments above are marked with "alt way:" for this solution
> 
> 
> 
> 
> Comment at: lldb/test/API/macosx/profile_vrs_detach/TestDetachVrsProfile.py:27
> +def test_profile_and_detach(self):
> +"""There can be many tests in a test case - describe this test 
> here."""
> +self.build()
> 
> fix comment?
> 
> 
> 
> Comment at: lldb/tools/debugserver/source/MacOSX/MachProcess.h:341-346
> +
> +  enum {
> +eMachProcessProfileNone = 0,
> +eMachProcessProfileCancel = (1 << 0)
> +  };
> +
> 
> Alt way (see main comment): remove these lines
> 
> 
> 
> Comment at: lldb/tools/debugserver/source/MacOSX/MachProcess.h:385
>   m_profile_data; // Profile data, must be protected by 
> m_profile_data_mutex
> -
> +  PThreadEvent m_profile_events; // Used for the profile thread cancellable 
> wait  
>   DNBThreadResumeActions m_thread_actions; // The thread actions for the 
> current
> 
> Alt way: remove
> 
> 
> 
> Comment at: lldb/tools/debugserver/source/MacOSX/MachProcess.mm:28
> #include 
> +#include 
> #include 
> 
> remove
> 
> 
> 
> Comment at: lldb/tools/debugserver/source/MacOSX/MachProcess.mm:34
> #include 
> +#include 
> #include 
> 
> remove
> 
> 
> 
> Comment at: lldb/tools/debugserver/source/MacOSX/MachProcess.mm:490
>   m_profile_data_mutex(PTHREAD_MUTEX_RECURSIVE), m_profile_data(),
> +  m_profile_events(0, eMachProcessProfileCancel),
>   m_thread_actions(), m_exception_messages(),
> 
> alt way: remove
> 
> 
> 
> Comment at: lldb/tools/debugserver/source/MacOSX/MachProcess.mm:1326
> +return;
> +  m_profile_events.SetEvents(eMachProcessProfileCancel);
> +  pthread_join(m_profile_thread, NULL);
> 
> alt way: 
> 
> ```
> m_profile_enabled = false;
> ```
> 
> 
> 
> 
> Comment at: lldb/tools/debugserver/source/MacOSX/MachProcess.mm:1329
> +  m_profile_thread = NULL;
> +  m_profile_events.ResetEvents(eMachProcessProfileCancel);
> +}
> 
> alt way: remove
> 
> 
> 
> Comment at: lldb/tools/debugserver/source/MacOSX/MachProcess.mm:2511-2538
>   while (proc->IsProfilingEnabled()) {
> nub_state_t state = proc->GetState();
> if (state == eStateRunning) {
>   std::string data =
>   proc->Task().GetProfileData(proc->GetProfileScanType());
>   if (!data.empty()) {
> proc->SignalAsyncProfileData(data.c_str());
> 
> Alt way: revert all changes here, when we call StopProfileThread, it will set 
> m_profile_enabled = false and this loop will naturally exit.
> 
> Your way: Move the conversion of profile interval out of the loop?
> 
> ```
> timespec ts;
> using namespace std::chrono;
> std::chrono::microseconds dur(proc->ProfileInterval());
> const auto dur_secs = duration_cast(dur);
> const auto dur_usecs = dur % std::chrono::seconds(1);
>  while (proc->IsProfilingEnabled()) {
>nub_state_t state = proc->GetState();
>if (state == eStateRunning) {
>  std::string data =
>  proc->Task().GetProfileData(proc->GetProfi

Re: [Lldb-commits] [PATCH] D74478: [lldb] Let TypeSystemClang::GetDisplayTypeName remove anonymous and inline namespaces.

[Jim Ingham via lldb-commits]

Yes, I don't think you have to solve this problem to make the suggested change. 
 

I think a lot of folks would appreciate the effort it would take to make names 
in backtraces more readable.  Sometimes, particularly when you use function 
objects and iterators in combination, the names are insanely long and pretty 
much impossible to read.  There's only so much we can tell from a mangled name 
- as opposed to having the full decl's, but I bet we could still get a pretty 
good compression from the tree-demangling and some heuristics.  So my main 
point was that we need to address shortening names in backtraces, but keeping 
them too long elsewhere isn't the right direction...

Jim


> On Feb 18, 2020, at 4:29 AM, Raphael Isemann via Phabricator 
>  wrote:
> 
> teemperor added a comment.
> 
> In D74478#1874746 , @jingham wrote:
> 
>> The only hesitation I have about this is if we are still printing this noise 
>> in demangled names, then the name of the type you see for a variable will be 
>> different from what you see when a method of that type ends up in a 
>> backtrace.  That might be confusing.  OTOH, the correct solution to that 
>> problem, IMO, is to remove the noise from backtraces, not keep it in the 
>> types...
> 
> 
> I'm not entirely sure how/if we can make the backtraces nicer as we only have 
> the function type (but not the specific function declaration with the name) 
> and mangled/demangled name for them. Removing the `anonymous namespace` from 
> the backtrace is doable with that, but inline namespaces and default template 
> arguments (which are part of the radar) aren't possible unless we start doing 
> much more work for the backtraces and figure out the actual FunctionDecls 
> behind each function.
> 
> FWIW, the current way we express backtraces is anyway not identical to what 
> we show in variables. Any typedefs and so on are lost in the mangled name, so 
> stepping into `std::string` member functions brings users to a backtrace with 
> in `std::__1::basic_string, 
> std::__1::allocator >::foo`. However printing the string shows them 
> `std::__1::string`.
> 
> 
> Repository:
>  rLLDB LLDB
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D74478/new/
> 
> https://reviews.llvm.org/D74478
> 
> 
> 

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

[Lldb-commits] [lldb] 4570f2c - Add a test for debugserver handling threads suspended from within a program.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-02-13T15:48:38-08:00
New Revision: 4570f2c7cf35388d8b3ab9cc5cdcad4971e31cf2

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

LOG: Add a test for debugserver handling threads suspended from within a 
program.

Mach allows you to suspend and resume other threads within a program, so
debugserver has to be careful not to interfere with this when it goes to supend 
and
resume threads while stepping over breakpoints and calling functions.  Even
trickier, if you call a function on a suspended thread, it has to resume the
thread to get the expression to run, and then suspend it properly when done.

This all works already, but there wasn't a test for it.  Adding that here.

This same test could be written for a unix that supports 
pthread_{suspend,resume}_np, but
macOS doesn't support these calls, only the mach version.  It doesn't look like
a lot of Linux'es support this (AIX does apparently...)  And IIUC Windows allows
you to suspend and resume other threads, but the code for that would look pretty
different than this main.c.  So for simplicity's sake I wrote this test for 
Darwin-only.

Added: 
lldb/test/API/macosx/thread_suspend/Makefile
lldb/test/API/macosx/thread_suspend/TestInternalThreadSuspension.py
lldb/test/API/macosx/thread_suspend/main.c

Modified: 


Removed: 




diff  --git a/lldb/test/API/macosx/thread_suspend/Makefile 
b/lldb/test/API/macosx/thread_suspend/Makefile
new file mode 100644
index ..695335e068c0
--- /dev/null
+++ b/lldb/test/API/macosx/thread_suspend/Makefile
@@ -0,0 +1,4 @@
+C_SOURCES := main.c
+CFLAGS_EXTRAS := -std=c99
+
+include Makefile.rules

diff  --git 
a/lldb/test/API/macosx/thread_suspend/TestInternalThreadSuspension.py 
b/lldb/test/API/macosx/thread_suspend/TestInternalThreadSuspension.py
new file mode 100644
index ..301b80058d3d
--- /dev/null
+++ b/lldb/test/API/macosx/thread_suspend/TestInternalThreadSuspension.py
@@ -0,0 +1,108 @@
+"""
+Make sure that if threads are suspended outside of lldb, debugserver
+won't make them run, even if we call an expression on the thread.
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+class TestSuspendedThreadHandling(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+NO_DEBUG_INFO_TESTCASE = True
+
+@skipUnlessDarwin
+def test_suspended_threads(self):
+"""Test that debugserver doesn't disturb the suspend count of a thread
+   that has been suspended from within a program, when navigating 
breakpoints
+   on other threads, or calling functions both on the suspended thread 
and
+   on other threads."""
+self.build()
+self.main_source_file = lldb.SBFileSpec("main.c")
+self.suspended_thread_test()
+
+def setUp(self):
+# Call super's setUp().
+TestBase.setUp(self)
+# Set up your test case here. If your test doesn't need any set up then
+# remove this method from your TestCase class.
+
+def try_an_expression(self, thread, correct_value, test_bp):
+frame = thread.frames[0]
+
+value = frame.EvaluateExpression('function_to_call()')
+self.assertTrue(value.GetError().Success(), "Successfully called the 
function")
+self.assertEqual(value.GetValueAsSigned(), correct_value, "Got 
expected value for expression")
+
+# Again, make sure we didn't let the suspend thread breakpoint run:
+self.assertEqual(test_bp.GetHitCount(), 0, "First expression allowed 
the suspend thread to run")
+
+
+def make_bkpt(self, pattern):
+bp = self.target.BreakpointCreateBySourceRegex(pattern, 
self.main_source_file)
+self.assertEqual(bp.GetNumLocations(), 1, "Locations for %s"%(pattern))
+return bp
+
+def suspended_thread_test(self):
+(self.target, process, thread, bkpt) = 
lldbutil.run_to_source_breakpoint(self,
+   "Stop here to get things going", 
self.main_source_file)
+
+# Make in the running thread, so the we will have to stop a number of 
times
+# while handling breakpoints.  The first couple of times we hit it we 
will
+# run expressions as well.  Make sure we don't let the suspended 
thread run
+# during those operations.
+rt_bp = self.make_bkpt("Break here to show we can handle breakpoints")
+
+# Make a breakpoint that we will hit when the running thread exits:
+rt_exit_bp = self.make_bkpt("Break here after thread_join")
+
+# Make a breakpoint in the suspended thread.  We should not hit this 
till we
+# resume it after joining the running thread.
+st_bp =

[Lldb-commits] [lldb] d62a343 - Add a test for adding and removing Listeners from a BroadcasterManager.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-02-07T17:54:25-08:00
New Revision: d62a343db23b7e8c3b5f2a0284bcacc10141a49e

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

LOG: Add a test for adding and removing Listeners from a BroadcasterManager.

Reid found a bug in removing Listeners from a BroadcasterManager:

https://reviews.llvm.org/D74010

The bug didn't affect the case where there was only one Listener
signed up for a BroadcasterManager, which was all the extant test
case tests.  The driver also only uses one listener (the debugger)
for everything, so neither the test nor anything you do with lldb
command line would have triggered the bug.

This adds a couple more tests using more listeners, and adding and
removing them in a different way, which triggers a separate code path.

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/api/listeners/TestListener.py

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/api/listeners/TestListener.py 
b/lldb/packages/Python/lldbsuite/test/api/listeners/TestListener.py
index 480041b3e1fc..a71ced961c05 100644
--- a/lldb/packages/Python/lldbsuite/test/api/listeners/TestListener.py
+++ b/lldb/packages/Python/lldbsuite/test/api/listeners/TestListener.py
@@ -2,8 +2,6 @@
 Test that we can listen to modules loaded events.
 """
 
-
-
 import lldb
 from lldbsuite.test.decorators import *
 from lldbsuite.test.lldbtest import *
@@ -11,12 +9,45 @@
 
 import six
 
-
 class ListenToModuleLoadedEvents (TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
+NO_DEBUG_INFO_TESTCASE = True
+
+def test_clearing_listener(self):
+"""Make sure we also clear listerers from the hook up for event type 
manager"""
+self.build()
+
+my_first_listener = lldb.SBListener("bonus_listener")
+my_listener = lldb.SBListener("test_listener")
+my_third_listener = lldb.SBListener("extra_bonus_listener")
 
-def test_receiving_breakpoint_added(self):
+my_listener.StartListeningForEventClass(
+self.dbg,
+lldb.SBTarget.GetBroadcasterClassName(),
+lldb.SBTarget.eBroadcastBitBreakpointChanged)
+my_first_listener.StartListeningForEventClass(
+self.dbg,
+lldb.SBTarget.GetBroadcasterClassName(),
+lldb.SBTarget.eBroadcastBitWatchpointChanged)
+my_third_listener.StartListeningForEventClass(
+self.dbg,
+lldb.SBTarget.GetBroadcasterClassName(),
+lldb.SBTarget.eBroadcastBitModulesUnloaded)
+
+exe = self.getBuildArtifact("a.out")
+
+my_listener.Clear()
+
+target = self.dbg.CreateTarget(exe)
+
+bkpt = target.BreakpointCreateByName("main")
+
+event = lldb.SBEvent()
+my_listener.WaitForEvent(1, event)
+self.assertTrue(not event.IsValid(), "We don't get events we aren't 
listening to.")
+
+def test_receiving_breakpoint_added_from_debugger(self):
 """Test that we get breakpoint added events, waiting on event classes 
on the debugger"""
 self.build()
 
@@ -47,7 +78,6 @@ def test_receiving_breakpoint_added(self):
 "It is our breakpoint.")
 
 # Now make sure if we stop listening for events we don't get them:
-
 my_listener.StopListeningForEventClass(
 self.dbg,
 lldb.SBTarget.GetBroadcasterClassName(),
@@ -55,9 +85,47 @@ def test_receiving_breakpoint_added(self):
 my_listener.StopListeningForEvents(
 target.GetBroadcaster(),
 lldb.SBTarget.eBroadcastBitBreakpointChanged)
-
+
 bkpt2 = target.BreakpointCreateByName("main")
 my_listener.WaitForEvent(1, event)
+self.assertTrue(not event.IsValid(), "We don't get events we aren't 
listening to.")
+
+def test_recieving_breakpoint_added_from_target(self):
+"""Test that we get breakpoint added events, waiting on event classes 
on the debugger"""
+self.build()
+
+my_listener = lldb.SBListener("test_listener")
+my_listener.StartListeningForEventClass(
+self.dbg,
+lldb.SBTarget.GetBroadcasterClassName(),
+lldb.SBTarget.eBroadcastBitBreakpointChanged)
+
+exe = self.getBuildArtifact("a.out")
+
+target = self.dbg.CreateTarget(exe)
+result = target.GetBroadcaster().AddListener(my_listener,
+ 
lldb.SBTarget.eBroadcastBitBreakpointChanged)
+self.assertEqual(result, 
lldb.SBTarget.eBroadcastBitBreakpointChanged,"Got our bit")
+
+bkpt = target.BreakpointCreateByName("main")
+
+event = lldb.SBEvent()
+my_listener.WaitForEvent(1, event)
+
+self.assertTrue(event.IsValid(), "Got a valid event.")

Re: [Lldb-commits] [lldb] c25938d - Refactor CommandObjectTargetSymbolsAdd::AddModuleSymbols

[Jim Ingham via lldb-commits]

The question isn't so much whether it makes a difference to the user than 
whether when somebody reports getting this error in a project that we can't get 
our hands on so all we have is the screen output (a very not uncommon 
circumstance for debuggers) the different error messages would be useful to 
us...

Jim


> On Feb 4, 2020, at 12:47 PM, Adrian McCarthy  wrote:
> 
> Given that the UUIDs in the test don't actually match, I think it's 
> reasonable for the error message to say it's not a match.  I'm not sure 
> detecting the problem in a different step of the process makes that much 
> difference to the user that it warrants a different message.  (I know it 
> sounds like I'm waffling.)
> 
> I'm happy to let others (e.g., Jason) make the call.  These are Darwin-only 
> tests, so I don't have a handy way to work through them.
> 
> On Tue, Feb 4, 2020 at 12:07 PM Jim Ingham  wrote:
> Seems like your change is more informative.  Could we just fix the tests?
> 
> Jim
> 
> 
> > On Feb 4, 2020, at 11:18 AM, Adrian McCarthy via lldb-commits 
> >  wrote:
> > 
> > I see why the behavior is different, but I'm not sure whether the new 
> > behavior is wrong.
> > 
> > The old code nested a bunch of if-success statements so that any failure 
> > would fall through to a default error message (the one the tests is 
> > expecting).
> > 
> > The new code is a linear set of if-failure-return statements so that 
> > failures at different steps get different messages.  (So, arguably, the new 
> > error message is more specific to the failure, even though it's worded 
> > rather vaguely.)
> > 
> > I can send a patch to use the original message for each of the three error 
> > types that are now distinct.
> > 
> > On Tue, Feb 4, 2020 at 8:49 AM Adrian McCarthy  wrote:
> > Sorry.  I can check this out this morning.
> > 
> > I didn't have any test failures locally, but I'm guessing that test doesn't 
> > run on Windows.
> > 
> > On Mon, Feb 3, 2020 at 6:43 PM Jason Molenda  wrote:
> > I'm going to xfail it for tonight; we end up copying the base filename into 
> > the ModuleSpec that we use for searching,
> > 
> > if (!module_spec.GetUUID().IsValid()) {
> >   if (!module_spec.GetFileSpec() && !module_spec.GetPlatformFileSpec())
> > module_spec.GetFileSpec().GetFilename() = 
> > symbol_fspec.GetFilename();
> > }
> > 
> > So when the binary is /dir1/a.out and the (wrong) dSYM is 
> > /dir2/a.out.dSYM/Contents/Resources/DWARF/a.out, and we did 'target symbols 
> > add /dir2/a.out.dSYM', "a.out" gets copied into module_spec and after 
> > Adrian's change, we search through the Target image list for a file called 
> > "a.out", find one (the wrong one), try to construct a ModuleSP with that as 
> > the ObjectFile and the /dir2/a.out.dSYM as the SymbolFile and it gets 
> > caught as inconsistent and we return the new, less helpful, error message.
> > 
> > I looked over his patch and I'm not sure where the logic went wrong here; 
> > I'll step through the old version tomorrow.
> > 
> > J
> > 
> > 
> > > On Feb 3, 2020, at 4:18 PM, Jason Molenda  wrote:
> > > 
> > > This is causing a test failure on the macos cmake bot in 
> > > TestAddDsymCommand.py where we load a binary with uuid A, then try to 
> > > add-dsym a dSYM uuid B and the test is looking for the error text,
> > > 
> > > error: symbol file 'FILENAME' does not match any existing module
> > > 
> > > but we're now getting,
> > > 
> > > error: the object file could not be loaded
> > > 
> > > and the test doesn't expect that.
> > > 
> > > 
> > > I'm looking into this, to see if I can get the more specific error 
> > > message back in here again.  I may xfail the test if I don't have a patch 
> > > done tonight.  I'd rather not test for this new generic error message if 
> > > it's avoidable.
> > > 
> > > 
> > > 
> > > 
> > > J
> > > 
> > > 
> > >> On Feb 3, 2020, at 2:22 PM, Adrian McCarthy via lldb-commits 
> > >>  wrote:
> > >> 
> > >> 
> > >> Author: Adrian McCarthy
> > >> Date: 2020-02-03T14:22:05-08:00
> > >> New Revision: c25938d57b1cf9534887313405bc409e570a9b69
> > >> 
> > >> URL: 
> > >> https://github.com/llvm/llvm-project/commit/c25938d57b1cf9534887313405bc409e570a9b69
> > >> DIFF: 
> > >> https://github.com/llvm/llvm-project/commit/c25938d57b1cf9534887313405bc409e570a9b69.diff
> > >> 
> > >> LOG: Refactor CommandObjectTargetSymbolsAdd::AddModuleSymbols
> > >> 
> > >> * [NFC] Renamed local `matching_module_list` to `matching_modules` for
> > >> conciseness.
> > >> 
> > >> * [NFC] Eliminated redundant local variable `num_matches` to reduce the 
> > >> risk
> > >> that changes get it out of sync with `matching_modules.GetSize()`.
> > >> 
> > >> * Used an early return from case where the symbol file specified matches
> > >> multiple modules.  This is a slight behavior change, but it's an 
> > >> improvement:
> > >> It didn't make sense to tell the user that the symbol file simultaneously
> > >> matched multiple modules and no modules.
> > >> 
> > >>

Re: [Lldb-commits] [lldb] c25938d - Refactor CommandObjectTargetSymbolsAdd::AddModuleSymbols

[Jim Ingham via lldb-commits]

Seems like your change is more informative.  Could we just fix the tests?

Jim


> On Feb 4, 2020, at 11:18 AM, Adrian McCarthy via lldb-commits 
>  wrote:
> 
> I see why the behavior is different, but I'm not sure whether the new 
> behavior is wrong.
> 
> The old code nested a bunch of if-success statements so that any failure 
> would fall through to a default error message (the one the tests is 
> expecting).
> 
> The new code is a linear set of if-failure-return statements so that failures 
> at different steps get different messages.  (So, arguably, the new error 
> message is more specific to the failure, even though it's worded rather 
> vaguely.)
> 
> I can send a patch to use the original message for each of the three error 
> types that are now distinct.
> 
> On Tue, Feb 4, 2020 at 8:49 AM Adrian McCarthy  wrote:
> Sorry.  I can check this out this morning.
> 
> I didn't have any test failures locally, but I'm guessing that test doesn't 
> run on Windows.
> 
> On Mon, Feb 3, 2020 at 6:43 PM Jason Molenda  wrote:
> I'm going to xfail it for tonight; we end up copying the base filename into 
> the ModuleSpec that we use for searching,
> 
> if (!module_spec.GetUUID().IsValid()) {
>   if (!module_spec.GetFileSpec() && !module_spec.GetPlatformFileSpec())
> module_spec.GetFileSpec().GetFilename() = symbol_fspec.GetFilename();
> }
> 
> So when the binary is /dir1/a.out and the (wrong) dSYM is 
> /dir2/a.out.dSYM/Contents/Resources/DWARF/a.out, and we did 'target symbols 
> add /dir2/a.out.dSYM', "a.out" gets copied into module_spec and after 
> Adrian's change, we search through the Target image list for a file called 
> "a.out", find one (the wrong one), try to construct a ModuleSP with that as 
> the ObjectFile and the /dir2/a.out.dSYM as the SymbolFile and it gets caught 
> as inconsistent and we return the new, less helpful, error message.
> 
> I looked over his patch and I'm not sure where the logic went wrong here; 
> I'll step through the old version tomorrow.
> 
> J
> 
> 
> > On Feb 3, 2020, at 4:18 PM, Jason Molenda  wrote:
> > 
> > This is causing a test failure on the macos cmake bot in 
> > TestAddDsymCommand.py where we load a binary with uuid A, then try to 
> > add-dsym a dSYM uuid B and the test is looking for the error text,
> > 
> > error: symbol file 'FILENAME' does not match any existing module
> > 
> > but we're now getting,
> > 
> > error: the object file could not be loaded
> > 
> > and the test doesn't expect that.
> > 
> > 
> > I'm looking into this, to see if I can get the more specific error message 
> > back in here again.  I may xfail the test if I don't have a patch done 
> > tonight.  I'd rather not test for this new generic error message if it's 
> > avoidable.
> > 
> > 
> > 
> > 
> > J
> > 
> > 
> >> On Feb 3, 2020, at 2:22 PM, Adrian McCarthy via lldb-commits 
> >>  wrote:
> >> 
> >> 
> >> Author: Adrian McCarthy
> >> Date: 2020-02-03T14:22:05-08:00
> >> New Revision: c25938d57b1cf9534887313405bc409e570a9b69
> >> 
> >> URL: 
> >> https://github.com/llvm/llvm-project/commit/c25938d57b1cf9534887313405bc409e570a9b69
> >> DIFF: 
> >> https://github.com/llvm/llvm-project/commit/c25938d57b1cf9534887313405bc409e570a9b69.diff
> >> 
> >> LOG: Refactor CommandObjectTargetSymbolsAdd::AddModuleSymbols
> >> 
> >> * [NFC] Renamed local `matching_module_list` to `matching_modules` for
> >> conciseness.
> >> 
> >> * [NFC] Eliminated redundant local variable `num_matches` to reduce the 
> >> risk
> >> that changes get it out of sync with `matching_modules.GetSize()`.
> >> 
> >> * Used an early return from case where the symbol file specified matches
> >> multiple modules.  This is a slight behavior change, but it's an 
> >> improvement:
> >> It didn't make sense to tell the user that the symbol file simultaneously
> >> matched multiple modules and no modules.
> >> 
> >> * [NFC] Used an early return from the case where no matches are found, to
> >> better align with LLVM coding style.
> >> 
> >> * [NFC] Simplified call of `AppendWarningWithFormat("%s", stuff)` to
> >> `AppendWarning(stuff)`.  I don't think this adds any copies.  It does
> >> construct a StringRef, but it was going to have to scan the string for the
> >> length anyway.
> >> 
> >> * [NFC] Removed unnecessary comments and reworded others for clarity.
> >> 
> >> * Used an early return if the symbol file could not be loaded.  This is a
> >> behavior change because previously it could fail silently.
> >> 
> >> * Used an early return if the object file could not be retrieved from the
> >> symbol file.  Again, this is a change because now there's an error message.
> >> 
> >> * [NFC] Eliminated a namespace alias that wasn't particularly helpful.
> >> 
> >> Differential Revision: https://reviews.llvm.org/D73594
> >> 
> >> Added: 
> >> 
> >> 
> >> Modified: 
> >>   lldb/source/Commands/CommandObjectTarget.cpp
> >> 
> >> Removed: 
> >> 
> >> 
> >> 
> >> ###

Re: [Lldb-commits] [lldb] r355466 - Replace debug-only assert with a plain old assert.

[Jim Ingham via lldb-commits]

That shouldn't be ASAN specific, that should happen on and 
LLDB_CONFIGURATION_DEBUG build.  If it only happens on ASAN builds, something 
else must be going wrong.

BTW, those asserts only make sense if you can't re-enter the command 
interpreter while a command is active.  In the case of a command that runs the 
target synchronously (like "step") with stop hooks or breakpoint commands, the 
"step" command won't have completed when you're running the commands in the 
stop hook or the breakpoint callback.  So that assumption is clearly not 
correct.

I don't think those asserts serve any useful purpose beyond reminding us that 
some day we really need to take the time to tease apart the part of 
CommandObject that forms the template for the command, and the part that 
represents this particular execution of that command.  

The CommandObject is a singleton, so it makes no sense for it to hold the data 
for any given execution.  We skate by on this for the most part because 
commands tend to do:

1) Store away the execution context for this command invocation
2) Parse Command Input into the option ivars in the CommandObject
3) Use those ivars to figure out what to do
4) Do It
5) Report a result that doesn't rely on the input data 

Since you don't generally get a chance to run another command till stage 4, it 
doesn't matter that that operation might overwrite the context or option ivars 
in the current CommandObject.  

This is clearly the wrong design, but unfortunately it has never caused any 
problems serious enough to motivate fixing it.

Jim

> On Jan 31, 2020, at 4:04 PM, Adrian Prantl  wrote:
> 
> This could be the known bug where a CommandObject is scheduled while the same 
> CommandObject is already deeper on the command stack. I tried digging up the 
> bugreport for that, but I couldn't find it.
> 
> -- adrian
> 
>> On Jan 31, 2020, at 3:59 PM, Vedant Kumar  wrote:
>> 
>> 
>> 
>>> On Mar 5, 2019, at 5:07 PM, Adrian Prantl via lldb-commits 
>>>  wrote:
>>> 
>>> Author: adrian
>>> Date: Tue Mar  5 17:07:45 2019
>>> New Revision: 355466
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=355466&view=rev
>>> Log:
>>> Replace debug-only assert with a plain old assert.
>>> 
>>> Modified:
>>>   lldb/trunk/source/Interpreter/CommandObject.cpp
>>> 
>>> Modified: lldb/trunk/source/Interpreter/CommandObject.cpp
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/CommandObject.cpp?rev=355466&r1=355465&r2=355466&view=diff
>>> ==
>>> --- lldb/trunk/source/Interpreter/CommandObject.cpp (original)
>>> +++ lldb/trunk/source/Interpreter/CommandObject.cpp Tue Mar  5 17:07:45 2019
>>> @@ -136,17 +136,15 @@ bool CommandObject::ParseOptions(Args &a
>>> }
>>> 
>>> bool CommandObject::CheckRequirements(CommandReturnObject &result) {
>>> -#ifdef LLDB_CONFIGURATION_DEBUG
>>>  // Nothing should be stored in m_exe_ctx between running commands as
>>>  // m_exe_ctx has shared pointers to the target, process, thread and frame 
>>> and
>>>  // we don't want any CommandObject instances to keep any of these objects
>>>  // around longer than for a single command. Every command should call
>>> -  // CommandObject::Cleanup() after it has completed
>>> -  assert(m_exe_ctx.GetTargetPtr() == NULL);
>>> -  assert(m_exe_ctx.GetProcessPtr() == NULL);
>>> -  assert(m_exe_ctx.GetThreadPtr() == NULL);
>>> -  assert(m_exe_ctx.GetFramePtr() == NULL);
>>> -#endif
>>> +  // CommandObject::Cleanup() after it has completed.
>>> +  assert(!m_exe_ctx.GetTargetPtr());
>> 
>> Hi all,
>> 
>> I'm actually hitting this assert now when I try debugging clang with a 
>> sanitized lldb. Any advice appreciated!
>> 
>> Stop hook #1 added.
>> (lldb) s
>> * thread #1, queue = 'com.apple.main-thread', stop reason = step in
>>  * frame #0: 0x0001044d2268 clang-10`clang::noteBottomOfStack() at 
>> Stack.cpp:42:8
>>frame #1: 0x00012295 clang-10`main(argc_=64, 
>> argv_=0x7ffeefbff160) at driver.cpp:342:3
>>frame #2: 0x7fff722ba3d5 libdyld.dylib`start + 1
>> 
>> Assertion failed: (!m_exe_ctx.GetTargetPtr()), function CheckRequirements, 
>> file 
>> /Users/vsk/src/llvm-project-master/lldb/source/Interpreter/CommandObject.cpp,
>>  line 153.
>> Stack dump:
>> 0.  Program arguments: 
>> /Users/vsk/src/builds/llvm-project-master-SAN/bin/lldb -o b main -o r -o 
>> target stop-hook add -o bt -o v -o s -o s -- 
>> /Users/vsk/src/builds/llvm-project-master-D/bin/clang-10 -cc1 -triple 
>> x86_64-apple-macosx10.14.0 -Wdeprecated-objc-isa-usage 
>> -Werror=deprecated-objc-isa-usage -emit-obj -disable-free -main-file-name 
>> sqlite3.c -mrelocation-model pic -pic-level 2 -mthread-model posix 
>> -mframe-pointer=all -fno-rounding-math -masm-verbose -munwind-tables 
>> -target-sdk-version=10.14 -target-cpu penryn -dwarf-column-info 
>> -debug-info-kind=standalone -dwarf-version=4 -debugger-tuning=lldb 
>> -target-linker-version 556 -resource-dir

[Lldb-commits] [lldb] 29c7e6c - Clang added a new feature to the ObjC compiler that will translate method

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-01-23T12:41:14-08:00
New Revision: 29c7e6c8c97f6b1186f012d614e9a1100e8c06cb

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

LOG: Clang added a new feature to the ObjC compiler that will translate method
calls to commonly un-overridden methods into a function that checks whether
the method is overridden anywhere and if not directly dispatches to the
NSObject implementation.

That means if you do override any of these methods, "step-in" will not step
into your code, since we hit the wrapper function, which has no debug info,
and immediately step out again.

Add code to recognize these functions as "trampolines" and a thread plan that
will get us from the function to the user code, if overridden.



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

Added: 
lldb/packages/Python/lldbsuite/test/lang/objc/direct-dispatch-step/Makefile

lldb/packages/Python/lldbsuite/test/lang/objc/direct-dispatch-step/TestObjCDirectDispatchStepping.py

lldb/packages/Python/lldbsuite/test/lang/objc/direct-dispatch-step/stepping-tests.m

Modified: 
lldb/include/lldb/Target/ThreadPlan.h
lldb/include/lldb/Target/ThreadPlanStepInRange.h

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.h

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h

Removed: 




diff  --git a/lldb/include/lldb/Target/ThreadPlan.h 
b/lldb/include/lldb/Target/ThreadPlan.h
index ff87ed23cda5..b25ee74766d4 100644
--- a/lldb/include/lldb/Target/ThreadPlan.h
+++ b/lldb/include/lldb/Target/ThreadPlan.h
@@ -461,8 +461,12 @@ class ThreadPlan : public 
std::enable_shared_from_this,
   virtual void WillPop();
 
   // This pushes a plan onto the plan stack of the current plan's thread.
+  // Also sets the plans to private and not master plans.  A plan pushed by 
+  // another thread plan is never either of the above.
   void PushPlan(lldb::ThreadPlanSP &thread_plan_sp) {
 m_thread.PushPlan(thread_plan_sp);
+thread_plan_sp->SetPrivate(false);
+thread_plan_sp->SetIsMasterPlan(false);
   }
 
   ThreadPlanKind GetKind() const { return m_kind; }

diff  --git a/lldb/include/lldb/Target/ThreadPlanStepInRange.h 
b/lldb/include/lldb/Target/ThreadPlanStepInRange.h
index a120c98fb36e..61ab475729aa 100644
--- a/lldb/include/lldb/Target/ThreadPlanStepInRange.h
+++ b/lldb/include/lldb/Target/ThreadPlanStepInRange.h
@@ -49,6 +49,12 @@ class ThreadPlanStepInRange : public ThreadPlanStepRange,
 
   bool IsVirtualStep() override;
 
+  // Plans that are implementing parts of a step in might need to follow the
+  // behavior of this plan w.r.t. StepThrough.  They can get that from here.
+  static uint32_t GetDefaultFlagsValue() {
+return s_default_flag_values;
+  }
+
 protected:
   static bool DefaultShouldStopHereCallback(ThreadPlan *current_plan,
 Flags &flags,

diff  --git 
a/lldb/packages/Python/lldbsuite/test/lang/objc/direct-dispatch-step/Makefile 
b/lldb/packages/Python/lldbsuite/test/lang/objc/direct-dispatch-step/Makefile
new file mode 100644
index ..9906470d5308
--- /dev/null
+++ 
b/lldb/packages/Python/lldbsuite/test/lang/objc/direct-dispatch-step/Makefile
@@ -0,0 +1,4 @@
+OBJC_SOURCES := stepping-tests.m
+LD_EXTRAS := -lobjc -framework Foundation
+
+include Makefile.rules

diff  --git 
a/lldb/packages/Python/lldbsuite/test/lang/objc/direct-dispatch-step/TestObjCDirectDispatchStepping.py
 
b/lldb/packages/Python/lldbsuite/test/lang/objc/direct-dispatch-step/TestObjCDirectDispatchStepping.py
new file mode 100644
index ..99ff5b805925
--- /dev/null
+++ 
b/lldb/packages/Python/lldbsuite/test/lang/objc/direct-dispatch-step/TestObjCDirectDispatchStepping.py
@@ -0,0 +1,50 @@
+"""Test stepping through ObjC method dispatch in various forms."""
+
+from __future__ import print_function
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestObjCDirectDispatchStepping(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+NO_DEBUG_INFO_TESTCASE = True
+
+def setUp(self):
+# Call super's setUp().
+TestBase.setUp(self)
+# Find the line numbers that we will step to in main:
+self.main_source = lldb.SBFileSpec("stepping-tests.m")
+
+@skipUnlessDarwin
+@add_test_categories(['pyapi', 'basic_process'])
+def test_with_python_api(self):
+"""Test stepping through the 'direct dispatch' optimized me

[Lldb-commits] [lldb] 89c8866 - Convert AssertTrue( A == B) to AssertEqual(A, B) in TestObjCStepping.py.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-01-22T13:20:15-08:00
New Revision: 89c8866c0417a415ab546aa870569308f15b0ec8

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

LOG: Convert AssertTrue( A == B) to AssertEqual(A, B) in TestObjCStepping.py.

Added: 


Modified: 

lldb/packages/Python/lldbsuite/test/lang/objc/objc-stepping/TestObjCStepping.py

Removed: 




diff  --git 
a/lldb/packages/Python/lldbsuite/test/lang/objc/objc-stepping/TestObjCStepping.py
 
b/lldb/packages/Python/lldbsuite/test/lang/objc/objc-stepping/TestObjCStepping.py
index bf80995b109d..8fb485847b44 100644
--- 
a/lldb/packages/Python/lldbsuite/test/lang/objc/objc-stepping/TestObjCStepping.py
+++ 
b/lldb/packages/Python/lldbsuite/test/lang/objc/objc-stepping/TestObjCStepping.py
@@ -106,21 +106,21 @@ def test_with_python_api(self):
 # Now step in, that should leave us in the Source randomMethod:
 thread.StepInto()
 line_number = thread.GetFrameAtIndex(0).GetLineEntry().GetLine()
-self.assertTrue(
-line_number == self.source_randomMethod_line,
+self.assertEqual(
+line_number, self.source_randomMethod_line,
 "Stepped into Source randomMethod.")
 
 # Now step in again, through the super call, and that should leave us
 # in the SourceBase randomMethod:
 thread.StepInto()
 line_number = thread.GetFrameAtIndex(0).GetLineEntry().GetLine()
-self.assertTrue(
-line_number == self.sourceBase_randomMethod_line,
+self.assertEqual(
+line_number, self.sourceBase_randomMethod_line,
 "Stepped through super into SourceBase randomMethod.")
 
 threads = lldbutil.continue_to_breakpoint(process, break2)
-self.assertTrue(
-len(threads) == 1,
+self.assertEqual(
+len(threads), 1,
 "Continued to second breakpoint in main.")
 
 # Again, step in twice gets us to a stret method and a stret super
@@ -128,21 +128,21 @@ def test_with_python_api(self):
 thread = threads[0]
 thread.StepInto()
 line_number = thread.GetFrameAtIndex(0).GetLineEntry().GetLine()
-self.assertTrue(
-line_number == self.source_returnsStruct_start_line,
+self.assertEqual(
+line_number, self.source_returnsStruct_start_line,
 "Stepped into Source returnsStruct.")
 
 threads = lldbutil.continue_to_breakpoint(
 process, break_returnStruct_call_super)
-self.assertTrue(
-len(threads) == 1,
+self.assertEqual(
+len(threads), 1,
 "Stepped to the call super line in Source returnsStruct.")
 thread = threads[0]
 
 thread.StepInto()
 line_number = thread.GetFrameAtIndex(0).GetLineEntry().GetLine()
-self.assertTrue(
-line_number == self.sourceBase_returnsStruct_start_line,
+self.assertEqual(
+line_number, self.sourceBase_returnsStruct_start_line,
 "Stepped through super into SourceBase returnsStruct.")
 
 # Cool now continue to get past the call that initializes the 
Observer, and then do our steps in again to see that
@@ -150,8 +150,8 @@ def test_with_python_api(self):
 # object.
 
 threads = lldbutil.continue_to_breakpoint(process, break3)
-self.assertTrue(
-len(threads) == 1,
+self.assertEqual(
+len(threads), 1,
 "Continued to third breakpoint in main, our object should now be 
swizzled.")
 
 newClassName = mySource_isa.GetSummary()
@@ -168,21 +168,21 @@ def test_with_python_api(self):
 thread = threads[0]
 thread.StepInto()
 line_number = thread.GetFrameAtIndex(0).GetLineEntry().GetLine()
-self.assertTrue(
-line_number == self.source_randomMethod_line,
+self.assertEqual(
+line_number, self.source_randomMethod_line,
 "Stepped into Source randomMethod in swizzled object.")
 
 # Now step in again, through the super call, and that should leave us
 # in the SourceBase randomMethod:
 thread.StepInto()
 line_number = thread.GetFrameAtIndex(0).GetLineEntry().GetLine()
-self.assertTrue(
-line_number == self.sourceBase_randomMethod_line,
+self.assertEqual(
+line_number, self.sourceBase_randomMethod_line,
 "Stepped through super into SourceBase randomMethod in swizzled 
object.")
 
 threads = lldbutil.continue_to_breakpoint(process, break4)
-self.assertTrue(
-len(threads) == 1,
+self.assertEqual(
+len(threads), 1,
 "Continued to fourth breakpoint in main.")
  

Re: [Lldb-commits] [PATCH] D72953: Fix the handling of unnamed bit-fields when parsing DWARF

[Jim Ingham via lldb-commits]

> On Jan 17, 2020, at 2:24 PM, Raphael Isemann via Phabricator 
>  wrote:
> 
> teemperor added a comment.
> 
> (Just some quick comments, will review this properly during normal working 
> hours)
> 
> Without this fix debugging Clang with LLDB is essentially impossible, so I'm 
> in favour of landing this with as few pre-commit refactorings as possible to 
> make backporting easier and getting this in ASAP. We probably also want to 
> ping Hans to get this into the 10 release branch (which was created 2 days 
> ago, so that's just a simple cherry-pick).

If you want to make back porting easier, you might not want to use expect_expr 
in the tests, since that would require back porting that as well as this patch?

Jim


> 
> Also you might want to check out the recently added `expect_expr` command 
> instead of calling `expect` (see the inline comment for an example). The API 
> currently doesn't support the whole fuzzy substr matching (which is on 
> purpose) so you might not be able to use it everywhere (at least the current 
> version).
> 
> 
> 
> 
> Comment at: 
> lldb/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py:207
> +
> +self.expect("expr (lba.a)", VARIABLES_DISPLAYED_CORRECTLY,
> +substrs=['unsigned int', '2'])
> 
> We can do this since last week: `self.expect_expr("(lba.a)", 
> result_type="unsigned int", result_value="2")` which is a much more safer and 
> convenient way of doing this.
> 
> 
> 
> Comment at: lldb/packages/Python/lldbsuite/test/lang/c/bitfields/main.c:128
> +  uint64_t HasNonTrivialToPrimitiveDestructCUnion : 1;
> +  uint64_t HasNonTrivialToPrimitiveCopyCUnion : 1;
> +};
> 
> I would prefer generic names as otherwise Clang folks randomly see the test 
> when they grep for usages of these variables by name in the LLVM repo.
> 
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D72953/new/
> 
> https://reviews.llvm.org/D72953
> 
> 
> 

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

Re: [Lldb-commits] LLDB Intel hardware breakpoints patch

[Jim Ingham via lldb-commits]

Somebody will have to champion this patch for it to get into lldb.  It has no 
test case, so it’s not acceptable as is.  It should also be cleaned up so that 
it shares more code with the watchpoint implementation in the same file (for 
instance duplicating all the comments and logic to set a hardware breakpoint 
vrs. a hardware watchpoint when they only differ by the size & read/write bits 
seems unfortunate.)

I don’t think the shared resource issue is actually a problem.  Both the 
watchpoint support and your additions call IsWatchpointVacant to find an 
available slot before using it so they won’t overwrite an already in use 
watchpoint.  That is certainly one of the things that should be included in a 
test case however.

I’m presuming you don’t intend to champion this patch yourself? 

Jim


> On Jan 17, 2020, at 8:20 AM, Reverser via lldb-commits 
>  wrote:
> 
> Hi,
>  
> Jonas Devlieghere asked me to send my patch to this mailing list because of 
> potential licensing issues.
>  
> It adds hardware breakpoints support for i386 and x86_64 architectures, 
> something that has been missing for a long time. I have written a blogpost 
> about it at 
> https://reverse.put.as/2019/11/19/how-to-make-lldb-a-real-debugger/ 
> .
>  
> Patch available in attachment and also here 
> https://github.com/gdbinit/llvmpatches 
> .
>  
> You most probably want to tweak it out and adapt to your project style. If 
> I'm not mistaken there is no count between hardware breakpoints and 
> watchpoints since they share the same resources. I didn't bother taking care 
> of that but it's something that should exist in production ready code.
>  
> I declared the patch code as public domain. If it makes your life easier I 
> can change it to whatever license you need, just tell me.
>  
> Best,
> Pedro
>  
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org 
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits 
> 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] cd9e5c3 - Fix the macos build after D71575.

[Jim Ingham via lldb-commits]

Author: Jim Ingham
Date: 2020-01-15T18:13:44-08:00
New Revision: cd9e5c32302cd3b34b796683eedb072c6a1cfdc1

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

LOG: Fix the macos build after D71575.

size_t and uint64_t are spelled slightly differently on macOS, which was
causing the compiler to error out calling std::min - since the two types have
to be the same.

I fixed this by casting the uint64_t computation to a size_t.  That's probably
not the cleanest solution, but it gets us back to building.

Added: 


Modified: 
lldb/source/Plugins/ObjectFile/wasm/ObjectFileWasm.cpp

Removed: 




diff  --git a/lldb/source/Plugins/ObjectFile/wasm/ObjectFileWasm.cpp 
b/lldb/source/Plugins/ObjectFile/wasm/ObjectFileWasm.cpp
index 1f636b719bb6..2c918a8f9db3 100644
--- a/lldb/source/Plugins/ObjectFile/wasm/ObjectFileWasm.cpp
+++ b/lldb/source/Plugins/ObjectFile/wasm/ObjectFileWasm.cpp
@@ -367,7 +367,7 @@ DataExtractor ObjectFileWasm::ReadImageData(uint64_t 
offset, size_t size) {
   DataExtractor data;
   if (m_file) {
 if (offset < GetByteSize()) {
-  size = std::min(size, GetByteSize() - offset);
+  size = std::min(size, (size_t) (GetByteSize() - offset));
   auto buffer_sp = MapFileData(m_file, size, offset);
   return DataExtractor(buffer_sp, GetByteOrder(), GetAddressByteSize());
 }



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

Re: [Lldb-commits] [PATCH] D72391: [lldb] Add a display name to ClangASTContext instances

[Jim Ingham via lldb-commits]

I think we should keep the pointer.  You can easily cast the pointer & call 
functions on it in the expression parser.  So if you have the log streaming as 
you are debugging and you see a log message that seems interesting, you can 
interrupt lldb and access the relevant context without having to find a 
variable pointing to it, or calling one of the lookup functions to find it.

Jim


> On Jan 8, 2020, at 5:01 PM, Greg Clayton via Phabricator via lldb-commits 
>  wrote:
> 
> clayborg added a comment.
> 
> I don't mess with the expression parser all that much, but do we still want 
> to see the pointer value in the log output?
> 
> current:
> 
>  CompleteTagDecl[2] on (ASTContext*)0x7ff31f01d240 Completing 
> (TagDecl*)0x7ff31f01d568 named DeclName1
> 
> Should the new one be
> 
>  CompleteTagDecl[2] on scratch ASTContext. Completing 
> (TagDecl*)0x7ff31f01d568 named Foo
> 
> Or include the pointer value **and** the name:
> 
>  CompleteTagDecl[2] on scratch (ASTContext*)0x7ff31f01d240. Completing 
> (TagDecl*)0x7ff31f01d568 named DeclName1
> 
> Might be nice to still see the pointer value in case there are multiple 
> ASTContexts with the same name?
> 
> 
> Repository:
>  rLLDB LLDB
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D72391/new/
> 
> https://reviews.llvm.org/D72391
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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