[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

2019-08-13 Thread Aaron Smith via Phabricator via lldb-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL368776: Update Python tests for lldb-server on Windows 
(authored by asmith, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D61687?vs=214985&id=214991#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D61687

Files:
  lldb/trunk/packages/Python/lldbsuite/test/dotest.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteAuxvSupport.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteKill.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteModuleInfo.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteProcessInfo.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteSingleStep.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteThreadsInStopReply.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_qThreadStopInfo.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_vCont.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/commandline/TestStubSetSID.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteSegFault.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
  
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py

Index: lldb/trunk/packages/Python/lldbsuite/test/dotest.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/dotest.py
+++ lldb/trunk/packages/Python/lldbsuite/test/dotest.py
@@ -1216,8 +1216,8 @@
 # Don't do debugserver tests on anything except OS X.
 configuration.dont_do_debugserver_test = "linux" in target_platform or "freebsd" in target_platform or "windows" in target_platform
 
-# Don't do lldb-server (llgs) tests on anything except Linux.
-configuration.dont_do_llgs_test = not ("linux" in target_platform)
+# Don't do lldb-server (llgs) tests on anything except Linux and Windows.
+configuration.dont_do_llgs_test = not ("linux" in target_platform) and not ("windows" in target_platform)
 
 # Collect tests from the specified testing directories. If a test
 # subdirectory filter is explicitly specified, limit the search to that
Index: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteProcessInfo.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteProcessInfo.py
+++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteProcessInfo.py
@@ -174,12 +174,11 @@
 self.build()
 self.qProcessInfo_contains_keys(set(['cputype', 'cpusubtype']))
 
-@skipUnlessPlatform(["linux"])
 @llgs_test
-def test_qProcessInfo_contains_triple_llgs_linux(self):
+def test_qProcessInfo_contains_triple_ppid_llgs(self):
 self.init_llgs_test()
 self.build()
-self.qProcessInfo_contains_keys(set(['triple']))
+self.qProcessInfo_contains_keys(set(['triple', 'parent-pid']))
 
 @skipUnlessDarwin
 @debugserver_test
@@ -202,9 +201,9 @@
 # for the remote Host and Process.
 self.qProcessInfo_does_not_contain_keys(set(['triple']))
 
-@skipUnlessPlatform(["linux"])
+@skipIfDarwin
 @llgs_test
-def test_qProcessInfo_does_not_contain_cputype_cpusubtype_llgs_linux(self):
+def test_qProcessInfo_does_not_contain_cputype_cpusubtype_llgs(self):
 self.init_llgs_test()
 self.build()
 self.qProcessInfo_does_not_contain_keys(set(['cputype', 'cpusubtype']))
Index: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_vCont.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_vCont.py
+++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_vCont.py
@@ -105,6 +105,7 @@
 self.single_step_only_steps_one_instruction(
 use_Hc_packet=True, step_instruction="vCont;s")
 
+@skipIfWindows # No pty support to test O* & I* notification packets.
 @llgs_test
 @expectedFailureAndroid(
 bu

[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

2019-08-13 Thread Aaron Smith via Phabricator via lldb-commits
asmith added a comment.

Any more comments on the tests for Windows?


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

https://reviews.llvm.org/D61687



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


[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

2019-08-13 Thread Aaron Smith via Phabricator via lldb-commits
asmith updated this revision to Diff 214985.
asmith edited the summary of this revision.

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

https://reviews.llvm.org/D61687

Files:
  packages/Python/lldbsuite/test/dotest.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteAuxvSupport.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteKill.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteModuleInfo.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteProcessInfo.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteSingleStep.py
  
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteThreadsInStopReply.py
  
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_qThreadStopInfo.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_vCont.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
  packages/Python/lldbsuite/test/tools/lldb-server/commandline/TestStubSetSID.py
  packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
  
packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
  
packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteSegFault.py
  packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
  
packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
  
packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py

Index: packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py
@@ -29,6 +29,7 @@
 kv_dict = self.parse_key_val_dict(context.get("key_vals_text"))
 self.assertEqual(expected_name, kv_dict.get("name"))
 
+@skipIfWindows # the test is not updated for Windows.
 @llgs_test
 def test(self):
 """ Make sure lldb-server can retrieve inferior thread name"""
Index: packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
@@ -81,6 +81,7 @@
 self.ignore_signals(signals_to_ignore)
 self.expect_exit_code(len(signals_to_ignore))
 
+@skipIfWindows # no signal support
 @llgs_test
 def test_default_signals_behavior(self):
 self.init_llgs_test()
Index: packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
@@ -925,6 +925,12 @@
 # Convert text pids to ints
 process_ids = [int(text_pid)
for text_pid in text_process_ids if text_pid != '']
+elif platform.system() == 'Windows':
+output = subprocess.check_output(
+"for /f \"tokens=2 delims=,\" %F in ('tasklist /nh /fi \"PID ne 0\" /fo csv') do @echo %~F", shell=True).decode("utf-8")
+text_process_ids = output.split('\n')[1:]
+process_ids = [int(text_pid)
+   for text_pid in text_process_ids if text_pid != '']
 # elif {your_platform_here}:
 #   fill in process_ids as a list of int type process IDs running on
 #   the local system.
Index: packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteSegFault.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteSegFault.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteSegFault.py
@@ -38,6 +38,7 @@
 self.build()
 self.inferior_seg_fault_received(self.GDB_REMOTE_STOP_CODE_BAD_ACCESS)
 
+@skipIfWindows # No signal is sent on Windows.
 @llgs_test
 def test_inferior_seg_fault_received_llgs(self):
 self.init_llgs_test()
Index: packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
@@ -36,6 +36,7 @@
 self.build()
 self.inferior_abort_received()
 
+@skipIfWindows # No signal is sent on Windows.
 @llgs_test
 # std::abort() on <= API 16 raises SIGSEGV -

[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

2019-05-20 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added a comment.

Ok, let's give this a shot.


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

https://reviews.llvm.org/D61687



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


[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

2019-05-18 Thread Aaron Smith via Phabricator via lldb-commits
asmith updated this revision to Diff 200160.

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

https://reviews.llvm.org/D61687

Files:
  packages/Python/lldbsuite/test/dotest.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteAuxvSupport.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteKill.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteModuleInfo.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteProcessInfo.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteSingleStep.py
  
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteThreadsInStopReply.py
  
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_qThreadStopInfo.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_vCont.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
  packages/Python/lldbsuite/test/tools/lldb-server/commandline/TestStubSetSID.py
  packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
  
packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
  
packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteSegFault.py
  packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
  
packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
  
packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py

Index: packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py
@@ -29,6 +29,7 @@
 kv_dict = self.parse_key_val_dict(context.get("key_vals_text"))
 self.assertEqual(expected_name, kv_dict.get("name"))
 
+@skipIfWindows # the test is not updated for Windows.
 @llgs_test
 def test(self):
 """ Make sure lldb-server can retrieve inferior thread name"""
Index: packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
@@ -81,6 +81,7 @@
 self.ignore_signals(signals_to_ignore)
 self.expect_exit_code(len(signals_to_ignore))
 
+@skipIfWindows # no signal support
 @llgs_test
 def test_default_signals_behavior(self):
 self.init_llgs_test()
Index: packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
@@ -926,6 +926,12 @@
 # Convert text pids to ints
 process_ids = [int(text_pid)
for text_pid in text_process_ids if text_pid != '']
+elif platform.system() == 'Windows':
+output = subprocess.check_output(
+"for /f \"tokens=2 delims=,\" %F in ('tasklist /nh /fi \"PID ne 0\" /fo csv') do @echo %~F", shell=True).decode("utf-8")
+text_process_ids = output.split('\n')[1:]
+process_ids = [int(text_pid)
+   for text_pid in text_process_ids if text_pid != '']
 # elif {your_platform_here}:
 #   fill in process_ids as a list of int type process IDs running on
 #   the local system.
Index: packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteSegFault.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteSegFault.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteSegFault.py
@@ -39,6 +39,7 @@
 self.build()
 self.inferior_seg_fault_received(self.GDB_REMOTE_STOP_CODE_BAD_ACCESS)
 
+@skipIfWindows # No signal is sent on Windows.
 @llgs_test
 def test_inferior_seg_fault_received_llgs(self):
 self.init_llgs_test()
Index: packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
@@ -37,6 +37,7 @@
 self.build()
 self.inferior_abort_received()
 
+@skipIfWindows # No signal is sent on Windows.
 @llgs_test
 # std::abort() on <= API 16 raises SIGSEGV - b.android.com/179836
 @expectedFailureA

[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

2019-05-16 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Thanks for explaining. I think this is good to go, sans the merging of the two 
tests I requested, and the comment fix that @clayborg noticed.




Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteThreadsInStopReply.py:208-212
+# In current implementation of llgs on Windows, as a response to '\x03' 
packet, the debugger
+# of the native process will trigger a call to DebugBreakProcess that will 
create a new thread
+# to handle the exception debug event. So one more stop thread will be 
notified to the
+# delegate, e.g. llgs.  So tests below to assert the stop threads number 
will all fail.
+@expectedFailureAll(oslist=["windows"])

Hui wrote:
> labath wrote:
> > labath wrote:
> > > Is this something that we consider to be a bug, or is it just how 
> > > debugging is supposed to work on windows? If it's a bug then fine, but if 
> > > not then we might consider adjusting the expectations in the test (or 
> > > just skipping it).
> > You marked this as done, but it's not obvious how is this comment resolved 
> > (or indeed, if it needs to be resolved). Can you elaborate?
> DebugBreakProcess is supposed to spawn a new thread in the debugged process 
> and then the thread exits after the irq is handled.
> 
> See below thread #1 is main thread of the debugged process and thread #2 is 
> the newly spawned.
> json string contains two stopped threads information.
> 
> looks like the stopped threads number is supposed to +1, but in order to be 
> consistent with Visual Studio,
> it shall be possible to only report the thread #1 stop info.
> 
> To modify the python script for Windows is at some cost. Maybe just skip them?
> 
> ```
> (lldb) process interrupt
>  GDBRemoteClientBase::Lock::Lock sent packet: \x03
> ...
>  <  16> send packet: $jThreadsInfo#c1
>  < 354> read packet: 
> $[{"name":"main.exe","reason":"trace","registers":{"16":"dc6b5a9af77f","6":"","7":"80fa1e8aca00"}],"tid":23108}],{"description":"Exception
>  0x8003 encountered at address 
> 0x7ffa1701e370","name":"main.exe","reason":"exception","registers":{"16":"71e30117fa7f","6":"","7":"28fa4f8aca00"}],"tid":23716}]]#f0
> 
> Process 27544 stopped
> * thread #1, name = 'main.exe', stop reason = trace
> frame #0: 0x7ff79a5a6bdc main.exe`main at main.cpp:7
>4{
>5
>6  printf("abc");
> -> 7  while(1);
>8  return 1;
>9}
>   thread #2, name = 'main.exe', stop reason = Exception 0x8003 
> encountered at address 0x7ffa1701e370
> frame #0: 0x7ffa1701e371
> ->  0x7ffa1701e371: retq
> 0x7ffa1701e372: int3
> 0x7ffa1701e373: int3
> 0x7ffa1701e374: int3
> ```
> 
Ok, I see. Hiding the thread sounds like the right thing to do, though I'm not 
sure if it should be done at lldb-server level. My feeling is it should be done 
at a higher level, because lldb-server should report the thing that the OS 
sees, and the OS definitely sees two threads here. It may be better to hide 
this in the higher levels of the debugger (unless the user has requested some 
sort of a verbose view).

If we go down that path, then I think it would be worth it to update these 
tests to have the correct expectation, but it does not have to happen now. We 
can leave them XFAILed for the time being. Thanks for explaining.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py:40
 
+@skipIfWindows # For now the signo in T* packet is always 0.
 @llgs_test

Hui wrote:
> labath wrote:
> > labath wrote:
> > > Do you have any plans for changing this? Given that windows does not 
> > > support signals, maybe it should stay 0...
> > I'd like to hear your thoughts on this...
> > 
> > If the idea is for the signal number to stay zero, then the comment 
> > shouldn't say "for now" but instead say something to the effect that 
> > abort() does not cause a signal to be raised on windows because windows 
> > doesn't have signals. If the idea is to change this later, then I'd like to 
> > understand how/why.
> I think the signal number can just stay zero (treated as invalid) unless 
> there is any strategy that will
> need valid ones in the future for Windows user-mode debugging(or for 
> kernel-mode debugging?). 
> The proposed implementation of native process/thread for windows in D56233 is 
> mainly signal free. 
> 
> There will be several slight difference(worth mentioning) by always filling 
> with zero signo
> 
> (1) In remote debugging case, T* packet is to detail the stopped reason for a 
> thread.
> W or w/o a valid signal the messages shown on lldb  are slightly different.
> (StopReason::eStopReasonBreakpoint vs StopReason::eStopReasonException)
> 
> On Linux,
> 
>  thread #1, name = 'a.out', stop reason = signal SIGSEGV: invalid address 
> (fault address: 0x0)
> 
> On Windows,
>  thread #1, name = 

[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

2019-05-15 Thread Hui Huang via Phabricator via lldb-commits
Hui added inline comments.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteThreadsInStopReply.py:208-212
+# In current implementation of llgs on Windows, as a response to '\x03' 
packet, the debugger
+# of the native process will trigger a call to DebugBreakProcess that will 
create a new thread
+# to handle the exception debug event. So one more stop thread will be 
notified to the
+# delegate, e.g. llgs.  So tests below to assert the stop threads number 
will all fail.
+@expectedFailureAll(oslist=["windows"])

labath wrote:
> labath wrote:
> > Is this something that we consider to be a bug, or is it just how debugging 
> > is supposed to work on windows? If it's a bug then fine, but if not then we 
> > might consider adjusting the expectations in the test (or just skipping it).
> You marked this as done, but it's not obvious how is this comment resolved 
> (or indeed, if it needs to be resolved). Can you elaborate?
DebugBreakProcess is supposed to spawn a new thread in the debugged process and 
then the thread exits after the irq is handled.

See below thread #1 is main thread of the debugged process and thread #2 is the 
newly spawned.
json string contains two stopped threads information.

looks like the stopped threads number is supposed to +1, but in order to be 
consistent with Visual Studio,
it shall be possible to only report the thread #1 stop info.

To modify the python script for Windows is at some cost. Maybe just skip them?

```
(lldb) process interrupt
 GDBRemoteClientBase::Lock::Lock sent packet: \x03
...
 <  16> send packet: $jThreadsInfo#c1
 < 354> read packet: 
$[{"name":"main.exe","reason":"trace","registers":{"16":"dc6b5a9af77f","6":"","7":"80fa1e8aca00"}],"tid":23108}],{"description":"Exception
 0x8003 encountered at address 
0x7ffa1701e370","name":"main.exe","reason":"exception","registers":{"16":"71e30117fa7f","6":"","7":"28fa4f8aca00"}],"tid":23716}]]#f0

Process 27544 stopped
* thread #1, name = 'main.exe', stop reason = trace
frame #0: 0x7ff79a5a6bdc main.exe`main at main.cpp:7
   4{
   5
   6  printf("abc");
-> 7  while(1);
   8  return 1;
   9}
  thread #2, name = 'main.exe', stop reason = Exception 0x8003 encountered 
at address 0x7ffa1701e370
frame #0: 0x7ffa1701e371
->  0x7ffa1701e371: retq
0x7ffa1701e372: int3
0x7ffa1701e373: int3
0x7ffa1701e374: int3
```



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

https://reviews.llvm.org/D61687



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


[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

2019-05-15 Thread Hui Huang via Phabricator via lldb-commits
Hui added inline comments.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py:40
 
+@skipIfWindows # For now the signo in T* packet is always 0.
 @llgs_test

labath wrote:
> labath wrote:
> > Do you have any plans for changing this? Given that windows does not 
> > support signals, maybe it should stay 0...
> I'd like to hear your thoughts on this...
> 
> If the idea is for the signal number to stay zero, then the comment shouldn't 
> say "for now" but instead say something to the effect that abort() does not 
> cause a signal to be raised on windows because windows doesn't have signals. 
> If the idea is to change this later, then I'd like to understand how/why.
I think the signal number can just stay zero (treated as invalid) unless there 
is any strategy that will
need valid ones in the future for Windows user-mode debugging(or for 
kernel-mode debugging?). 
The proposed implementation of native process/thread for windows in D56233 is 
mainly signal free. 

There will be several slight difference(worth mentioning) by always filling 
with zero signo

(1) In remote debugging case, T* packet is to detail the stopped reason for a 
thread.
W or w/o a valid signal the messages shown on lldb  are slightly different.
(StopReason::eStopReasonBreakpoint vs StopReason::eStopReasonException)

On Linux,

 thread #1, name = 'a.out', stop reason = signal SIGSEGV: invalid address 
(fault address: 0x0)

On Windows,
 thread #1, name = 'a.out', stop reason = Exception 0xc005 encountered at 
address 0x7ff6011c1093
 
(2) The GDB remote serial protocol does have several signals related packets,
like **"vCont;S"** to resume a thread by single stepping with signal or** 
"vCont;C"** to continue with signal.
For example, **vCont;S06** to single step with signo=6 (SIGABRT).

Such packets won't be available on Windows.  The continuation of a stopped 
thread relies on how
the exception is dispatched and handled.  This is mentioned at

https://docs.microsoft.com/en-us/windows/desktop/debug/exception-dispatching

In this python test case, if a segfault happens, the EXCEPTION_ACCESS_VIOLATION 
(0xc005) is raised.
Since there is no eh installed in user application, the exception will be 
dispatched to lldb Debugger for the second time
where a default eh or ExitProcess will be called.  ( D56233 patch might need 
such changes)




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

https://reviews.llvm.org/D61687



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


[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

2019-05-15 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added inline comments.



Comment at: packages/Python/lldbsuite/test/dotest.py:1313
 
 # Don't do lldb-server (llgs) tests on anything except Linux.
+configuration.dont_do_llgs_test = not ("linux" in target_platform) and not 
("windows" in target_platform)

Update comment


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

https://reviews.llvm.org/D61687



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


[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

2019-05-15 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteProcessInfo.py:205-217
 @skipUnlessPlatform(["linux"])
 @llgs_test
 def test_qProcessInfo_does_not_contain_cputype_cpusubtype_llgs_linux(self):
 self.init_llgs_test()
 self.build()
 self.qProcessInfo_does_not_contain_keys(set(['cputype', 'cpusubtype']))
+

These two tests can also be merged and made `@skipIfDarwin` as that is the only 
platform using the cpu(sub)type fields.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteThreadsInStopReply.py:208-212
+# In current implementation of llgs on Windows, as a response to '\x03' 
packet, the debugger
+# of the native process will trigger a call to DebugBreakProcess that will 
create a new thread
+# to handle the exception debug event. So one more stop thread will be 
notified to the
+# delegate, e.g. llgs.  So tests below to assert the stop threads number 
will all fail.
+@expectedFailureAll(oslist=["windows"])

labath wrote:
> Is this something that we consider to be a bug, or is it just how debugging 
> is supposed to work on windows? If it's a bug then fine, but if not then we 
> might consider adjusting the expectations in the test (or just skipping it).
You marked this as done, but it's not obvious how is this comment resolved (or 
indeed, if it needs to be resolved). Can you elaborate?



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_qThreadStopInfo.py:146-153
 # All but one thread should report no stop reason.
-self.assertEqual(no_stop_reason_count, thread_count - 1)
+triple = self.dbg.GetSelectedPlatform().GetTriple()
+
+# Consider one more thread created by calling DebugBreakProcess.
+if re.match(".*-.*-windows", triple):
+self.assertGreaterEqual(no_stop_reason_count, thread_count - 1)
+else:

labath wrote:
> I think this assertion should just be deleted. If the assertion below (that 
> one thread has a stop reason) is true, then it trivially true that the rest 
> of the threads don't have one. Whether or not a platforms spawns an extra 
> thread does not seem to be relevant for this test.
This comment doesn't appear to be "done".



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py:40
 
+@skipIfWindows # For now the signo in T* packet is always 0.
 @llgs_test

labath wrote:
> Do you have any plans for changing this? Given that windows does not support 
> signals, maybe it should stay 0...
I'd like to hear your thoughts on this...

If the idea is for the signal number to stay zero, then the comment shouldn't 
say "for now" but instead say something to the effect that abort() does not 
cause a signal to be raised on windows because windows doesn't have signals. If 
the idea is to change this later, then I'd like to understand how/why.


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

https://reviews.llvm.org/D61687



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


[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

2019-05-14 Thread Aaron Smith via Phabricator via lldb-commits
asmith updated this revision to Diff 199554.

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

https://reviews.llvm.org/D61687

Files:
  packages/Python/lldbsuite/test/dotest.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteAuxvSupport.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteKill.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteModuleInfo.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteProcessInfo.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteSingleStep.py
  
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteThreadsInStopReply.py
  
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_qThreadStopInfo.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_vCont.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
  packages/Python/lldbsuite/test/tools/lldb-server/commandline/TestStubSetSID.py
  packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
  
packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
  packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
  
packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
  
packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py

Index: packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py
@@ -29,6 +29,7 @@
 kv_dict = self.parse_key_val_dict(context.get("key_vals_text"))
 self.assertEqual(expected_name, kv_dict.get("name"))
 
+@skipIfWindows # the test is not updated for Windows.
 @llgs_test
 def test(self):
 """ Make sure lldb-server can retrieve inferior thread name"""
Index: packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
@@ -81,6 +81,7 @@
 self.ignore_signals(signals_to_ignore)
 self.expect_exit_code(len(signals_to_ignore))
 
+@skipIfWindows # no signal support
 @llgs_test
 def test_default_signals_behavior(self):
 self.init_llgs_test()
Index: packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
@@ -926,6 +926,12 @@
 # Convert text pids to ints
 process_ids = [int(text_pid)
for text_pid in text_process_ids if text_pid != '']
+elif platform.system() == 'Windows':
+output = subprocess.check_output(
+"for /f \"tokens=2 delims=,\" %F in ('tasklist /nh /fi \"PID ne 0\" /fo csv') do @echo %~F", shell=True).decode("utf-8")
+text_process_ids = output.split('\n')[1:]
+process_ids = [int(text_pid)
+   for text_pid in text_process_ids if text_pid != '']
 # elif {your_platform_here}:
 #   fill in process_ids as a list of int type process IDs running on
 #   the local system.
Index: packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
@@ -37,6 +37,7 @@
 self.build()
 self.inferior_abort_received()
 
+@skipIfWindows # For now the signo in T* packet is always 0.
 @llgs_test
 # std::abort() on <= API 16 raises SIGSEGV - b.android.com/179836
 @expectedFailureAndroid(api_levels=list(range(16 + 1)))
Index: packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
@@ -235,6 +235,10 @@
 # Remote platforms don't support named pipe based port negotiation
 use_named_pipe = False
 
+triple = self.dbg.GetSelectedPlatform().GetTriple()
+if re.match(".*-.*-windows", triple):
+self.skipTest("Remotely testing is not supported on Windows yet.")
+
 # Grab the ppi

[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

2019-05-14 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteModuleInfo.py:24-27
+# Replace path separators in the json string either with "" or "/" 
on Windows.
+triple = self.dbg.GetSelectedPlatform().GetTriple()
+if re.match(".*-.*-windows", triple):
+module_path = module_path.replace(os.path.sep, '/')

Hui wrote:
> clayborg wrote:
> > labath wrote:
> > > It sounds like you could just unconditionally replace all backslashes 
> > > with double-backslashes here. That would result in us also correctly 
> > > handling posix paths that happen to contain a backslash.
> > Remove
> The 'jModulesInfo' packet is a json string. I tested with json.loads as 
> follows.
> It seemed to me that module_path needs to be escaped, i.e. 'd:abc' or be  
> 'd:/abc'.
> 
> not-working case:
> 
> ```
> >>> module_path = 'd:\abc'
> >>> json.dumps(module_path)
> '"d:\\u0007bc"'
> >>> json.loads('[{"[file":"%s"}]' % json.dumps(module_path))
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/json/__init__.py", line 339, in loads
> return _default_decoder.decode(s)
>   File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
> obj, end = self.raw_decode(s, idx=_w(s, 0).end())
>   File "/usr/lib/python2.7/json/decoder.py", line 380, in raw_decode
> obj, end = self.scan_once(s, idx)
> ValueError: Expecting , delimiter: line 1 column 13 (char 12)
> 
> ```
> working case:
> 
> ```
> >>> module_path = 'd:abc'
> >>> json.loads('[{"[file":"%s"}]' % module_path)
> [{u'[file': u'd:\\abc'}]
> ```
> 
> 
> 
There are multiple levels of quoting happening here, and I believe you're 
getting them mixed up:
> >>> module_path = 'd:\abc'
This is already wrong, because python will interpret the \a as the ASCII BEL 
character, resulting in the string consisting of: 'd', ':', BEL, 'b', 'c'
```
>>> "d:\abc"
'd:\x07bc'
```
The easiest fix is to use "raw" python strings:
```
r"d:\abc"
'd:\\abc'
```
Note that the '\' in the output string it's not doubled, it is just how the 
python dumper makes sure the output is unambiguous. You can for instance check 
that with: `len(r"d:\abc")` which returns `6` as expected.

After that, your not-working case works almost fine:
```
>>> json.loads('[{"[file":"%s"}]' % json.dumps(module_path))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.6/json/__init__.py", line 354, in loads
return _default_decoder.decode(s)
  File "/usr/lib64/python3.6/json/decoder.py", line 339, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib64/python3.6/json/decoder.py", line 355, in raw_decode
obj, end = self.scan_once(s, idx)
json.decoder.JSONDecodeError: Expecting ',' delimiter: line 1 column 13 (char 
12)
>>> json.loads('[{"[file":%s}]' % json.dumps(module_path))
[{'[file': 'd:\\abc'}]
```
Note I removed the superfluous quotes in the second attempt. However, if we're 
going to be using the json package for this, then there's an even simpler way 
to write this:
```
>>> json.dumps([{"file": module_path}])
'[{"file": "d:abc"}]'
>>> json.loads(json.dumps([{"file": module_path}]))
[{'file': 'd:\\abc'}]
```


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D61687



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


[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

2019-05-13 Thread Hui Huang via Phabricator via lldb-commits
Hui added inline comments.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteModuleInfo.py:24-27
+# Replace path separators in the json string either with "" or "/" 
on Windows.
+triple = self.dbg.GetSelectedPlatform().GetTriple()
+if re.match(".*-.*-windows", triple):
+module_path = module_path.replace(os.path.sep, '/')

clayborg wrote:
> labath wrote:
> > It sounds like you could just unconditionally replace all backslashes with 
> > double-backslashes here. That would result in us also correctly handling 
> > posix paths that happen to contain a backslash.
> Remove
The 'jModulesInfo' packet is a json string. I tested with json.loads as follows.
It seemed to me that module_path needs to be escaped, i.e. 'd:abc' or be  
'd:/abc'.

not-working case:

```
>>> module_path = 'd:\abc'
>>> json.dumps(module_path)
'"d:\\u0007bc"'
>>> json.loads('[{"[file":"%s"}]' % json.dumps(module_path))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/json/__init__.py", line 339, in loads
return _default_decoder.decode(s)
  File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python2.7/json/decoder.py", line 380, in raw_decode
obj, end = self.scan_once(s, idx)
ValueError: Expecting , delimiter: line 1 column 13 (char 12)

```
working case:

```
>>> module_path = 'd:abc'
>>> json.loads('[{"[file":"%s"}]' % module_path)
[{u'[file': u'd:\\abc'}]
```





Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D61687



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


[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

2019-05-09 Thread Greg Clayton via Phabricator via lldb-commits
clayborg requested changes to this revision.
clayborg added inline comments.
This revision now requires changes to proceed.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteKill.py:17
 def attach_commandline_kill_after_initial_stop(self):
+reg_expr = r"^\$X[0-9a-fA-F]+([^#]*)#[0-9A-Fa-f]{2}"
+triple = self.dbg.GetSelectedPlatform().GetTriple()

labath wrote:
> If I understand correctly, the regexes differ only in the first letter. If 
> that's the case, then you could just factor out the rest of the regex and 
> just compute the letter differently:
> ```
> stop_type = 'W' if windows else 'X'
> reg_expr = r"^\${}...".format(stop_type)
> ```
Just make one if there can be two letters?:

reg_expr = r"^\$[XW][0-9a-fA-F]+([^#]*)#[0-9A-Fa-f]{2}"




Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteKill.py:20-23
+# No signal support on Windwos. Only W* response is sent.
+if re.match(".*-.*-windows", triple):
+reg_expr = r"^\$W[0-9a-fA-F]+([^#]*)#[0-9A-Fa-f]{2}"
+

Remove



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteModuleInfo.py:22
 
+module_path = lldbutil.append_to_process_working_directory(self, 
"a.out")
+

Use json.dumps:
```
module_path = json.dumps(lldbutil.append_to_process_working_directory(self, 
"a.out"))
```



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteModuleInfo.py:24-27
+# Replace path separators in the json string either with "" or "/" 
on Windows.
+triple = self.dbg.GetSelectedPlatform().GetTriple()
+if re.match(".*-.*-windows", triple):
+module_path = module_path.replace(os.path.sep, '/')

labath wrote:
> It sounds like you could just unconditionally replace all backslashes with 
> double-backslashes here. That would result in us also correctly handling 
> posix paths that happen to contain a backslash.
Remove



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteSingleStep.py:23
 
+@skipIfWindows # No pty support to test any inferior std -i/e/o
 @llgs_test

We probably don't need pty support just to support STDIO redirection to a child 
process we spawn. That is how it is done for linux, but doens't need to be how 
it is done on windows. Be great if we can fix this.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_qThreadStopInfo.py:59-61
+# On Windows, there could be more threads spawned. For example, 
DebugBreakProcess will
+# create a new thread from the debugged process to handle an exception 
event. So here we
+# assert 'GreaterEqual' condition.

Will this always be "thread_count+1" for window? Or can there be more threads.

This leads to a higher level question: Does the user ever want to see the 
"DebugBreakProcess" thread in the IDE? Should we just never report this thread 
from lldb-server and avoid these mismatch issues? We should be consistent with 
what other windows debuggers do (show DebugBreakProcess or not).



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_vCont.py:108
 
+@skipIfWindows # No pty support to test O* & I* notification packets.
 @llgs_test

We probably don't need pty support just to support STDIO redirection to a child 
process we spawn. That is how it is done for linux, but doens't need to be how 
it is done on windows. Be great if we can fix this.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D61687



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


[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

2019-05-09 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.
Herald added a subscriber: dexonsmith.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteKill.py:17-23
+reg_expr = r"^\$X[0-9a-fA-F]+([^#]*)#[0-9A-Fa-f]{2}"
+triple = self.dbg.GetSelectedPlatform().GetTriple()
+
+# No signal support on Windwos. Only W* response is sent.
+if re.match(".*-.*-windows", triple):
+reg_expr = r"^\$W[0-9a-fA-F]+([^#]*)#[0-9A-Fa-f]{2}"
+

If I understand correctly, the regexes differ only in the first letter. If 
that's the case, then you could just factor out the rest of the regex and just 
compute the letter differently:
```
stop_type = 'W' if windows else 'X'
reg_expr = r"^\${}...".format(stop_type)
```



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteModuleInfo.py:24-27
+# Replace path separators in the json string either with "" or "/" 
on Windows.
+triple = self.dbg.GetSelectedPlatform().GetTriple()
+if re.match(".*-.*-windows", triple):
+module_path = module_path.replace(os.path.sep, '/')

It sounds like you could just unconditionally replace all backslashes with 
double-backslashes here. That would result in us also correctly handling posix 
paths that happen to contain a backslash.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteProcessInfo.py:178-191
 @skipUnlessPlatform(["linux"])
 @llgs_test
 def test_qProcessInfo_contains_triple_llgs_linux(self):
 self.init_llgs_test()
 self.build()
 self.qProcessInfo_contains_keys(set(['triple']))
 

I'm not sure why the original test was made linux-specific, but I think you can 
just drop the os name from the test and have a single test which checks for 
both the presence of `parent-pid` and `triple`. No `@skipUnless` needed as all 
platforms that currently have a working lldb-server should support these fields.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteThreadsInStopReply.py:208-212
+# In current implementation of llgs on Windows, as a response to '\x03' 
packet, the debugger
+# of the native process will trigger a call to DebugBreakProcess that will 
create a new thread
+# to handle the exception debug event. So one more stop thread will be 
notified to the
+# delegate, e.g. llgs.  So tests below to assert the stop threads number 
will all fail.
+@expectedFailureAll(oslist=["windows"])

Is this something that we consider to be a bug, or is it just how debugging is 
supposed to work on windows? If it's a bug then fine, but if not then we might 
consider adjusting the expectations in the test (or just skipping it).



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_qThreadStopInfo.py:146-153
 # All but one thread should report no stop reason.
-self.assertEqual(no_stop_reason_count, thread_count - 1)
+triple = self.dbg.GetSelectedPlatform().GetTriple()
+
+# Consider one more thread created by calling DebugBreakProcess.
+if re.match(".*-.*-windows", triple):
+self.assertGreaterEqual(no_stop_reason_count, thread_count - 1)
+else:

I think this assertion should just be deleted. If the assertion below (that one 
thread has a stop reason) is true, then it trivially true that the rest of the 
threads don't have one. Whether or not a platforms spawns an extra thread does 
not seem to be relevant for this test.



Comment at: 
packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py:40
 
+@skipIfWindows # For now the signo in T* packet is always 0.
 @llgs_test

Do you have any plans for changing this? Given that windows does not support 
signals, maybe it should stay 0...


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D61687



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


[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows

2019-05-08 Thread Aaron Smith via Phabricator via lldb-commits
asmith created this revision.
asmith added reviewers: labath, rnk.
Herald added a reviewer: jfb.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Repository:
  rLLDB LLDB

https://reviews.llvm.org/D61687

Files:
  packages/Python/lldbsuite/test/dotest.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteAuxvSupport.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteKill.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteModuleInfo.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteProcessInfo.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteSingleStep.py
  
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteThreadsInStopReply.py
  
packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_qThreadStopInfo.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemote_vCont.py
  packages/Python/lldbsuite/test/tools/lldb-server/TestLldbGdbServer.py
  packages/Python/lldbsuite/test/tools/lldb-server/commandline/TestStubSetSID.py
  packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
  
packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
  packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
  
packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
  
packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py

Index: packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/thread-name/TestGdbRemoteThreadName.py
@@ -29,6 +29,7 @@
 kv_dict = self.parse_key_val_dict(context.get("key_vals_text"))
 self.assertEqual(expected_name, kv_dict.get("name"))
 
+@skipIfWindows # the test is not updated for Windows.
 @llgs_test
 def test(self):
 """ Make sure lldb-server can retrieve inferior thread name"""
Index: packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/signal-filtering/TestGdbRemote_QPassSignals.py
@@ -81,6 +81,7 @@
 self.ignore_signals(signals_to_ignore)
 self.expect_exit_code(len(signals_to_ignore))
 
+@skipIfWindows # no signal support
 @llgs_test
 def test_default_signals_behavior(self):
 self.init_llgs_test()
Index: packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py
@@ -926,6 +926,12 @@
 # Convert text pids to ints
 process_ids = [int(text_pid)
for text_pid in text_process_ids if text_pid != '']
+elif platform.system() == 'Windows':
+output = subprocess.check_output(
+"for /f \"tokens=2 delims=,\" %F in ('tasklist /nh /fi \"PID ne 0\" /fo csv') do @echo %~F", shell=True).decode("utf-8")
+text_process_ids = output.split('\n')[1:]
+process_ids = [int(text_pid)
+   for text_pid in text_process_ids if text_pid != '']
 # elif {your_platform_here}:
 #   fill in process_ids as a list of int type process IDs running on
 #   the local system.
Index: packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/inferior-crash/TestGdbRemoteAbort.py
@@ -37,6 +37,7 @@
 self.build()
 self.inferior_abort_received()
 
+@skipIfWindows # For now the signo in T* packet is always 0.
 @llgs_test
 # std::abort() on <= API 16 raises SIGSEGV - b.android.com/179836
 @expectedFailureAndroid(api_levels=list(range(16 + 1)))
Index: packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
===
--- packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
+++ packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
@@ -235,6 +235,10 @@
 # Remote platforms don't support named pipe based port negotiation
 use_named_pipe = False
 
+triple = self.dbg.GetSelectedPlatform().GetTriple()
+if re.match(".*-.*-windows", triple):
+self.skipTest