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

Wed May 15 18:30:59 PDT 2019

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 0xc0000005 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 (0xc0000005) 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