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)

thread #1, name = 'a.out', stop reason = Exception 0xc0000005 encountered at address 0x7ff6011c1093

That sounds like the right thing to report, as that is what actually happened.

vCont;S06

Yeah, I think lldb-server on windows should just not support these packets (return an error or something). I don't know if there is a concept of "injecting" exceptions on windows, but if there is, we can have a discussion later on how to implement that.

So overall I think skipping this test is the right thing to do. I just think the message giving the reason could be a bit better. Maybe just "abort() does not send a signal on windows" ?