[Lldb-commits] [PATCH] D61687: Update Python tests for lldb-server on Windows
Hui Huang via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
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.
> 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)
thread #1, name = 'a.out', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
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
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
More information about the lldb-commits