[Lldb-commits] [PATCH] D70830: [LLDB] Disable MSVC warning C4190

2021-05-06 Thread Martin Storsjö via Phabricator via lldb-commits 
mstorsjo added a comment.

Just for the record, the issue seems to be this:

  $ cat cpp-ret-c.cpp 
  template class MyClass {
  public:
  T a;
  };
  extern "C" MyClass unmangledFunction();
  $ cl -c cpp-ret-c.cpp 
  cpp-ret-c.cpp
  cpp-ret-c.cpp(5): error C2526: 'unmangledFunction': C linkage function cannot 
return C++ class 'MyClass' 
  cpp-ret-c.cpp(5): note: see declaration of 'MyClass'
  $ cat cpp-ret-c2.cpp 
  template class MyClass {
  public:
  T a;
  };
  MyClass unusedFunc() { return MyClass{0}; }
  extern "C" MyClass unmangledFunction();
  $ cl -c cpp-ret-c2.cpp
  cpp-ret-c2.cpp

So this construct, in MSVC, requires that the problematic return type template 
already has been instantiated somewhere else first. The case in the python 
plugin works, but it has been copied to the Lua plugin too, where it fails.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70830

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

[Lldb-commits] [PATCH] D70830: [LLDB] Disable MSVC warning C4190

2021-05-06 Thread Martin Storsjö via Phabricator via lldb-commits 
mstorsjo added a comment.

In D70830#2742960 , @aganea wrote:

> Hello @mstorsjo! I've reverted the patch locally, I'm at this commit:
>
>   F:\aganea\llvm-project>git log
>   commit a3a8a1a15b524d91b5308db68e9d293b34cd88dd (HEAD -> main, origin/main)
>
> Using:
>
>   F:\aganea\llvm-project>cl
>   Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29914 for x64
>
> that is, Visual Studio 16.9.4 running a "x64 Native Tools Command Prompt for 
> VS 2019".
>
> Building with:
>
>   cmake "-DLLVM_LIT_ARGS=-sv -j 36" -GNinja 
> -DLLVM_ENABLE_PROJECTS=llvm;clang;lld;lldb -DLLVM_ENABLE_LIBXML2=OFF 
> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON %ROOT%/llvm 
> -DLLVM_OPTIMIZED_TABLEGEN=ON -DCMAKE_C_COMPILER=cl -DCMAKE_CXX_COMPILER=cl 
> -DCMAKE_LINKER=link
>
> The invocation:
>
>   [4/10] 
> C:\PROGRA~2\MICROS~4\2019\PROFES~1\VC\Tools\MSVC\1428~1.299\bin\Hostx64\x64\cl.exe
>   /nologo /TP -DGTEST_HAS_RTTI=0 
> -DLLDB_PYTHON_RELATIVE_LIBDIR=\"Lib/site-packages\" -DUNICODE 
> -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS 
> -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS 
> -D_ENABLE_EXTENDED_ALIGNED_STORAGE -D_HAS_EXCEPTIONS=0 
> -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE 
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
> -Itools\lldb\source\Plugins\ScriptInterpreter\Python 
> -IF:\aganea\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python 
> -Itools\lldb\source -IF:\aganea\llvm-project\lldb\include 
> -Itools\lldb\include -Iinclude -IF:\aganea\llvm-project\llvm\include 
> -I"C:\Program Files\Python39\include" 
> -IF:\aganea\llvm-project\llvm\..\clang\include -Itools\lldb\..\clang\include 
> -IF:\aganea\llvm-project\lldb\source\. /DWIN32 /D_WINDOWS   /Zc:inline 
> /Zc:__cplusplus /Zc:strictStrings /Oi /Zc:rvalueCast /bigobj /W4 -wd4141 
> -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458 -wd4459 
> -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 
> -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 
> -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd4324 -w14062 -we4238 /Gw 
> /MD /O2 /Ob2   -wd4018 -wd4068 -wd4150 -wd4201 -wd4251 -wd4521 -wd4530  
> /EHs-c- /GR- -UNDEBUG -std:c++14 /showIncludes 
> /Fotools\lldb\source\Plugins\ScriptInterpreter\Python\CMakeFiles\lldbPluginScriptInterpreterPython.dir\ScriptInterpreterPython.cpp.obj
>  
> /Fdtools\lldb\source\Plugins\ScriptInterpreter\Python\CMakeFiles\lldbPluginScriptInterpreterPython.dir\lldbPluginScriptInterpreterPython.pdb
>  /FS -c 
> F:\aganea\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python\ScriptInterpreterPython.cpp
>   
> F:\aganea\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python\ScriptInterpreterPython.cpp(83):
>  warning C4190: 'LLDBSwigPythonBreakpointCallbackFunction' has C-linkage 
> specified, but returns UDT 'llvm::Expected' which is incompatible with C
>   
> F:\aganea\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python\PythonDataObjects.h(355):
>  note: see declaration of 'llvm::Expected'

Thanks for testing!

Sorry, I hadn't actually tried configuring LLDB to enable python - I'm looking 
into a similar case in the Lua plugin (where the same construct allegedly is 
causing errors), and I've tried to copy that snippet from the python plugin 
into a separate file, and there it errors out. But when actually building the 
python plugin as such, it does indeed succeed. That should be enough for me to 
dig into the matter - thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70830

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

[Lldb-commits] [PATCH] D101933: If an interrupt fails, don't try to fetch any more packets from the server

2021-05-06 Thread Jim Ingham via Phabricator via lldb-commits 
jingham added a comment.

I moved the eStateExited test as Greg suggested on commit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101933

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

[Lldb-commits] [PATCH] D101933: If an interrupt fails, don't try to fetch any more packets from the server

2021-05-06 Thread Jim Ingham via Phabricator via lldb-commits 
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG72ba78c29e92: When SendContinuePacketAndWaitForResponse 
returns eStateInvalid, dont fetch… (authored by jingham).

Changed prior to commit:
  https://reviews.llvm.org/D101933?vs=343131=343499#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101933

Files:
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/test/API/functionalities/gdb_remote_client/TestHaltFails.py

Index: lldb/test/API/functionalities/gdb_remote_client/TestHaltFails.py
===
--- /dev/null
+++ lldb/test/API/functionalities/gdb_remote_client/TestHaltFails.py
@@ -0,0 +1,72 @@
+from __future__ import print_function
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+from gdbclientutils import *
+
+
+class TestHaltFails(GDBRemoteTestBase):
+
+class MyResponder(MockGDBServerResponder):
+
+def setBreakpoint(self, packet):
+return "OK"
+
+def interrupt(self):
+# Simulate process waiting longer than the interrupt
+# timeout to stop, then sending the reply.
+time.sleep(14)
+return "T02reason:signal"
+
+def cont(self):
+# No response, wait for the client to interrupt us.
+return None
+
+def wait_for_and_check_event(self, wait_time, value):
+event = lldb.SBEvent()
+got_event = self.dbg.GetListener().WaitForEvent(wait_time, event)
+self.assertTrue(got_event, "Failed to get event after wait")
+self.assertTrue(lldb.SBProcess.EventIsProcessEvent(event), "Event was not a process event")
+event_type = lldb.SBProcess.GetStateFromEvent(event)
+self.assertEqual(event_type, value)
+
+def get_to_running(self):
+self.server.responder = self.MyResponder()
+self.target = self.createTarget("a.yaml")
+process = self.connect(self.target)
+self.dbg.SetAsync(True)
+
+# There should be a stopped event, consume that:
+self.wait_for_and_check_event(2, lldb.eStateStopped)
+process.Continue()
+
+# There should be a running event, consume that:
+self.wait_for_and_check_event(2, lldb.eStateRunning)
+return process
+
+@skipIfReproducer # FIXME: Unexpected packet during (passive) replay
+def test_destroy_while_running(self):
+process = self.get_to_running()
+process.Destroy()
+
+# Again pretend that after failing to be interrupted, we delivered the stop
+# and make sure we still exit properly.
+self.wait_for_and_check_event(14, lldb.eStateExited)
+
+@skipIfReproducer # FIXME: Unexpected packet during (passive) replay
+def test_async_interrupt(self):
+"""
+Test that explicitly calling AsyncInterrupt, which then fails, leads
+to an "eStateExited" state.
+"""
+process = self.get_to_running()
+# Now do the interrupt:
+process.SendAsyncInterrupt()
+
+# That should have caused the Halt to time out and we should
+# be in eStateExited:
+self.wait_for_and_check_event(15, lldb.eStateExited)
+
+
+
+
Index: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
===
--- lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -3689,12 +3689,25 @@
 __FUNCTION__, arg, process->GetID());
 
   EventSP event_sp;
+
+  // We need to ignore any packets that come in after we have
+  // have decided the process has exited.  There are some
+  // situations, for instance when we try to interrupt a running
+  // process and the interrupt fails, where another packet might
+  // get delivered after we've decided to give up on the process.
+  // But once we've decided we are done with the process we will
+  // not be in a state to do anything useful with new packets.
+  // So it is safer to simply ignore any remaining packets by
+  // explicitly checking for eStateExited before reentering the
+  // fetch loop.
+  
   bool done = false;
-  while (!done) {
+  while (!done && process->GetPrivateState() != eStateExited) {
 LLDB_LOGF(log,
   "ProcessGDBRemote::%s (arg = %p, pid = %" PRIu64
   ") listener.WaitForEvent (NULL, event_sp)...",
   __FUNCTION__, arg, process->GetID());
+
 if (process->m_async_listener_sp->GetEvent(event_sp, llvm::None)) {
   const uint32_t event_type = event_sp->GetType();
   if (event_sp->BroadcasterIs(>m_async_broadcaster)) {
@@ -3793,6 +3806,7 @@
 } else {

[Lldb-commits] [lldb] 72ba78c - When SendContinuePacketAndWaitForResponse returns eStateInvalid, don't fetch more packets.

2021-05-06 Thread Jim Ingham via lldb-commits 

Author: Jim Ingham
Date: 2021-05-06T14:11:42-07:00
New Revision: 72ba78c29e923cb6e5d89eb5ea8180bf723188be

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

LOG: When SendContinuePacketAndWaitForResponse returns eStateInvalid, don't 
fetch more packets.

This looks like just an oversight in the AsyncThread function.  It gets a 
result of
eStateInvalid, and then marks the process as exited, but doesn't set "done" to 
true,
so we go to fetch another event.  That is not safe, since you don't know when 
that
extra packet is going to arrive.  If it arrives while you are tearing down the
process, the internal-state-thread might try to handle it when the process in 
not
in a good state.

Rather than put more effort into checking all the shutdown paths to make sure 
this
extra packet doesn't cause problems, just don't fetch it.  We weren't going to 
do
anything useful with it anyway.

The main part of the patch is setting "done = true" when we get the 
eStateInvalid.
I also added a check at the beginning of the while(done) loop to prevent 
another error
from getting us to fetch packets for an exited process.

I added a test case to ensure that if an Interrupt fails, we call the process
exited.  I can't test exactly the error I'm fixing, there's no good way to know
that the stop reply for the failed interrupt wasn't fetched.  But at least this
asserts that the overall behavior is correct.

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

Added: 
lldb/test/API/functionalities/gdb_remote_client/TestHaltFails.py

Modified: 
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index 5ff00f8566990..f8e0567aeddb3 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -3689,12 +3689,25 @@ thread_result_t ProcessGDBRemote::AsyncThread(void 
*arg) {
 __FUNCTION__, arg, process->GetID());
 
   EventSP event_sp;
+
+  // We need to ignore any packets that come in after we have
+  // have decided the process has exited.  There are some
+  // situations, for instance when we try to interrupt a running
+  // process and the interrupt fails, where another packet might
+  // get delivered after we've decided to give up on the process.
+  // But once we've decided we are done with the process we will
+  // not be in a state to do anything useful with new packets.
+  // So it is safer to simply ignore any remaining packets by
+  // explicitly checking for eStateExited before reentering the
+  // fetch loop.
+  
   bool done = false;
-  while (!done) {
+  while (!done && process->GetPrivateState() != eStateExited) {
 LLDB_LOGF(log,
   "ProcessGDBRemote::%s (arg = %p, pid = %" PRIu64
   ") listener.WaitForEvent (NULL, event_sp)...",
   __FUNCTION__, arg, process->GetID());
+
 if (process->m_async_listener_sp->GetEvent(event_sp, llvm::None)) {
   const uint32_t event_type = event_sp->GetType();
   if (event_sp->BroadcasterIs(>m_async_broadcaster)) {
@@ -3793,6 +3806,7 @@ thread_result_t ProcessGDBRemote::AsyncThread(void *arg) {
 } else {
   process->SetExitStatus(-1, "lost connection");
 }
+done = true;
 break;
   }
 

diff  --git a/lldb/test/API/functionalities/gdb_remote_client/TestHaltFails.py 
b/lldb/test/API/functionalities/gdb_remote_client/TestHaltFails.py
new file mode 100644
index 0..9f8e39e8ecca5
--- /dev/null
+++ b/lldb/test/API/functionalities/gdb_remote_client/TestHaltFails.py
@@ -0,0 +1,72 @@
+from __future__ import print_function
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+from gdbclientutils import *
+
+
+class TestHaltFails(GDBRemoteTestBase):
+
+class MyResponder(MockGDBServerResponder):
+
+def setBreakpoint(self, packet):
+return "OK"
+
+def interrupt(self):
+# Simulate process waiting longer than the interrupt
+# timeout to stop, then sending the reply.
+time.sleep(14)
+return "T02reason:signal"
+
+def cont(self):
+# No response, wait for the client to interrupt us.
+return None
+
+def wait_for_and_check_event(self, wait_time, value):
+event = lldb.SBEvent()
+got_event = self.dbg.GetListener().WaitForEvent(wait_time, event)
+self.assertTrue(got_event, "Failed to get event after wait")
+self.assertTrue(lldb.SBProcess.EventIsProcessEvent(event),

[Lldb-commits] [PATCH] D70830: [LLDB] Disable MSVC warning C4190

2021-05-06 Thread Alexandre Ganea via Phabricator via lldb-commits 
aganea added a comment.

Hello @mstorsjo! I've reverted the patch locally, I'm at this commit:

  F:\aganea\llvm-project>git log
  commit a3a8a1a15b524d91b5308db68e9d293b34cd88dd (HEAD -> main, origin/main)

Using:

  F:\aganea\llvm-project>cl
  Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29914 for x64

that is, Visual Studio 16.9.4 running a "x64 Native Tools Command Prompt for VS 
2019".

Building with:

  cmake "-DLLVM_LIT_ARGS=-sv -j 36" -GNinja 
-DLLVM_ENABLE_PROJECTS=llvm;clang;lld;lldb -DLLVM_ENABLE_LIBXML2=OFF 
-DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON %ROOT%/llvm 
-DLLVM_OPTIMIZED_TABLEGEN=ON -DCMAKE_C_COMPILER=cl -DCMAKE_CXX_COMPILER=cl 
-DCMAKE_LINKER=link

The invocation:

  [4/10] 
C:\PROGRA~2\MICROS~4\2019\PROFES~1\VC\Tools\MSVC\1428~1.299\bin\Hostx64\x64\cl.exe
  /nologo /TP -DGTEST_HAS_RTTI=0 
-DLLDB_PYTHON_RELATIVE_LIBDIR=\"Lib/site-packages\" -DUNICODE 
-D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS 
-D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS 
-D_ENABLE_EXTENDED_ALIGNED_STORAGE -D_HAS_EXCEPTIONS=0 
-D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Itools\lldb\source\Plugins\ScriptInterpreter\Python 
-IF:\aganea\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python 
-Itools\lldb\source -IF:\aganea\llvm-project\lldb\include -Itools\lldb\include 
-Iinclude -IF:\aganea\llvm-project\llvm\include -I"C:\Program 
Files\Python39\include" -IF:\aganea\llvm-project\llvm\..\clang\include 
-Itools\lldb\..\clang\include -IF:\aganea\llvm-project\lldb\source\. /DWIN32 
/D_WINDOWS   /Zc:inline /Zc:__cplusplus /Zc:strictStrings /Oi /Zc:rvalueCast 
/bigobj /W4 -wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 
-wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 
-wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 
-wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd4324 -w14062 -we4238 /Gw /MD 
/O2 /Ob2   -wd4018 -wd4068 -wd4150 -wd4201 -wd4251 -wd4521 -wd4530  /EHs-c- 
/GR- -UNDEBUG -std:c++14 /showIncludes 
/Fotools\lldb\source\Plugins\ScriptInterpreter\Python\CMakeFiles\lldbPluginScriptInterpreterPython.dir\ScriptInterpreterPython.cpp.obj
 
/Fdtools\lldb\source\Plugins\ScriptInterpreter\Python\CMakeFiles\lldbPluginScriptInterpreterPython.dir\lldbPluginScriptInterpreterPython.pdb
 /FS -c 
F:\aganea\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python\ScriptInterpreterPython.cpp
  
F:\aganea\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python\ScriptInterpreterPython.cpp(83):
 warning C4190: 'LLDBSwigPythonBreakpointCallbackFunction' has C-linkage 
specified, but returns UDT 'llvm::Expected' which is incompatible with C
  
F:\aganea\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python\PythonDataObjects.h(355):
 note: see declaration of 'llvm::Expected'


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70830

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

[Lldb-commits] [PATCH] D70830: [LLDB] Disable MSVC warning C4190

2021-05-06 Thread Martin Storsjö via Phabricator via lldb-commits 
mstorsjo added a comment.

Hi @aganea, I'm a but curious about this change - how did you manage to make 
this work with MSVC? In my experience, this construct doesn't produce warning 
C4190 (which this silences) with MSVC, but produces error C2526 (which I don't 
think can be silenced).

See e.g. https://gcc.godbolt.org/z/s1Mr6dPr5 for an example of this construct, 
which fails with MSVC. (It seems to fail in the same way with all versions 
ranging from 2010 to 2019.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70830

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

[Lldb-commits] [PATCH] D101237: [lldb] Fix [[no_unique_address]] and libstdc++ 11's std::unique_ptr

2021-05-06 Thread Jan Kratochvil via Phabricator via lldb-commits 
jankratochvil reclaimed this revision.
jankratochvil added a comment.

Reopening as D101950  may take some time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101237

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

[Lldb-commits] [PATCH] D101237: [lldb] Fix [[no_unique_address]] and libstdc++ 11's std::unique_ptr

2021-05-06 Thread Jan Kratochvil via Phabricator via lldb-commits 
jankratochvil abandoned this revision.
jankratochvil added a comment.

IIUC it will get replaced by D101950 .
I will just provide some testcase for this case if not already contained 
therein.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101237

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

[Lldb-commits] [lldb] 3026f75 - [lldb][NFC] Make assert in TestStaticVariables more expressive

2021-05-06 Thread Raphael Isemann via lldb-commits 

Author: Raphael Isemann
Date: 2021-05-06T16:00:24+02:00
New Revision: 3026f75ed0f520f9be7ac354406687a549155ded

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

LOG: [lldb][NFC] Make assert in TestStaticVariables more expressive

Added: 


Modified: 
lldb/test/API/lang/cpp/class_static/TestStaticVariables.py

Removed: 




diff  --git a/lldb/test/API/lang/cpp/class_static/TestStaticVariables.py 
b/lldb/test/API/lang/cpp/class_static/TestStaticVariables.py
index 3a065452ab742..d5e2c8fdb2486 100644
--- a/lldb/test/API/lang/cpp/class_static/TestStaticVariables.py
+++ b/lldb/test/API/lang/cpp/class_static/TestStaticVariables.py
@@ -151,8 +151,8 @@ def test_with_python_api(self):
 self.DebugSBValue(child1)
 child1_x = child1.GetChildAtIndex(0)
 self.DebugSBValue(child1_x)
-self.assertTrue(child1_x.GetTypeName() == 'int' and
-child1_x.GetValue() == '11')
+self.assertEqual(child1_x.GetTypeName(), 'int')
+self.assertEqual(child1_x.GetValue(), '11')
 
 # SBFrame.FindValue() should also work.
 val = frame.FindValue("A::g_points", lldb.eValueTypeVariableGlobal)



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

[Lldb-commits] [PATCH] D95601: [lldb][AArch64] Add memory tag reading to lldb-server

2021-05-06 Thread David Spickett via Phabricator via lldb-commits 
DavidSpickett added inline comments.



Comment at: lldb/test/API/tools/lldb-server/memory-tagging/main.c:53
+  // smoke test in case something didn't account for them.
+  buf = (char *)((size_t)buf | ((size_t)0xAA << 56));
+  return print_result(buf);

omjavaid wrote:
> Just a side question about TBI, for memroy reads/write or tags/query is it 
> necessary to send non address bits to remote? (tags and pauth masks). Can we 
> instead clear these bits before sending address over using the code/data 
> masks we have calculated in our host process class.
You shouldn't need to include them as the stripped address is equivalent as far 
as ptrace is concerned.

If you were gonna JIT some code and use it to load from that address then yes 
we'd need the bits.

That said, I'm not sure lldb-server can make the assumption that they are 
stripped. At least for reading memory tags, I'll have to think about it since 
the protocol doesn't require the client to remove tag bits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95601

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