labath added a comment. In D128410#3604927 <https://reviews.llvm.org/D128410#3604927>, @alvinhochun wrote:
> It may be possible to stuff a pointer to an `EXCEPTION_RECORD` into another > `EXCEPTION_RECORD` and use `RtlRaiseException` to generate the exception, but > you'll have to test how it actually works. That would be pretty cool. ================ Comment at: lldb/test/Shell/Process/Windows/wndproc_exception.cpp:7 +// RUN: %clangxx_host -o %t.exe -luser32 -v -- %s +// RUN: %lldb -f %t.exe -o "run" + ---------------- alvinhochun wrote: > alvinhochun wrote: > > mstorsjo wrote: > > > mstorsjo wrote: > > > > labath wrote: > > > > > Is there something reasonable we could assert here? The process exit > > > > > status for instance? > > > > This in itself requires the `%lldb` command to succeed - the exit > > > > status for each `RUN` line needs to be successful (unless a failure is > > > > expected and it can be inverted with the `not` command). Or did you > > > > mean checking the process exit code of the child process (that > > > > intentionally does crash)? > > > > > > > > When this test case is run, it prints the following to the terminal: > > > > ``` > > > > (lldb) run > > > > Process 3168 stopped > > > > * thread #1, stop reason = Exception 0xc000041d encountered at address > > > > 0x7ff68e6f1227 > > > > frame #0: 0x00007ff68e6f1227 wndproc_exception.cpp.tmp.exe > > > > -> 0x7ff68e6f1227: movl $0x1, (%rax) > > > > 0x7ff68e6f122d: movq $0x0, 0x50(%rsp) > > > > 0x7ff68e6f1236: jmp 0x7ff68e6f1259 > > > > 0x7ff68e6f123b: movq 0x48(%rsp), %r9 > > > > Process 3168 launched: > > > > 'C:\dev\llvm-project\llvm\build-msvc\tools\lldb\test\Shell\Process\Windows\Output\wndproc_exception.cpp.tmp.exe' > > > > (x86_64) > > > > ``` > > > > I guess we could check for `Exception 0xc000041d encountered` maybe, > > > > although I'm afraid of making the testcase unnecessarily brittle too. > > > If running with lldb-server enabled, it prints a different exception > > > code, `0xc0000005` (which is `STATUS_ACCESS_VIOLATION`) which probably is > > > the proper nested exception, while without lldb-server, it prints > > > `0xc000041d` (`STATUS_FATAL_USER_CALLBACK_EXCEPTION`). > > > > > > So for the purpose of this testcase, just to make sure that it doesn't > > > crash in this case, it'd be better to not specify exactly which exception > > > code is to be returned. > > It may be that lldb-server is catching the first chance > > `STATUS_ACCESS_VIOLATION` exception before the exception is passed to the > > exception handler... > If you test with windbg or gdb, you will get the access violation / sigsegv > first, and only after continuing the debuggee you will get the `0xc000041d` > exception. > This in itself requires the `%lldb` command to succeed - the exit status for > each `RUN` line needs to be successful (unless a failure is expected and it > can be inverted with the `not` command). Or did you mean checking the process > exit code of the child process (that intentionally does crash)? Yes, that's what I mean, but I don't think we need to match the precise exception number (although probably only one of those two numbers is really "correct"). We could just match the `stop reason = Exception` part. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D128410/new/ https://reviews.llvm.org/D128410 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
