mstorsjo added a subscriber: stella.stamenova. mstorsjo added a comment. In D128410#3604075 <https://reviews.llvm.org/D128410#3604075>, @labath wrote:
> In D128410#3604066 <https://reviews.llvm.org/D128410#3604066>, @mstorsjo > wrote: > >> For this testcase to work, it needs to be able to open a window - so it >> can't run entirely in headless mode. But I guess that a bunch of other tests >> in LLDB also already do that, since running the LLDB tests on Windows pops >> up a dozen of windows temporarily. > > I think those just come from the tests (or more like test runners) which > forget to suppress a console window from opening (see > LLDB_LAUNCH_INFERIORS_WITHOUT_CONSOLE) -- this is probably the first "gui" > application. This isn't necessarily a showstopper, but I am surprised that it > is necessary. I'm hardly a windows expert, but I would expect that it should > be possible to generate an exception (even nested exception, which to me > sounds like the equivalent of getting a signal inside a signal handler) in a > "regular" text-mode application. Are you sure that is not possible? I didn't say that this isn't necessarily possible - this is the reduced testcase that @alvinhochun provided in https://github.com/mstorsjo/llvm-mingw/issues/292#issuecomment-1160239522 (that I shrunk down further a bit). I'm not all that familiar with exactly what happens in these APIs here that makes this a nested exception and what other non-GUI APIs would produce the same effect. Maybe any API where Windows system code calls back to a user provided callback? Does @stella.stamenova know? ================ 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" + ---------------- 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. 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
