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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
