[Lldb-commits] [PATCH] D67776: Use UnixSignals::ShouldSuppress to filter out signals a process expects

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

This is an interesting problem. As Jim suspects, breakpoint int3s come out as stop reason = breakpoint in lldb, and non-breakpoint int3 as SIGTRAP. So, in theory, it should be possible to change the SIGTRAP behavior so that it does not impact SIGTRAPs from lldb-generated breakpoints, though it will require some fiddling with the `QPassSignals` packet -- the way it's implemented now is that it would bypass the stop reason determination and forcefully reinject all signals (even the "debugger generated" ones into the process).

That said, I'm not sure this is actually a good idea. :) One of the uses of application-generated SIGTRAPs I've seen (and used) was to implement a poor man's "fast conditional breakpoint" -- you insert something like `if (do_i_want_to_stop) int3()` into the code, and let the application run under a debugger. The intention here is to be able to continue the program from this "breakpoint" and this will only work if the debugger does not reinject the SIGTRAP.

Now, this is not a super common pattern, so it might be fine to just ask to user to change the SIGTRAP disposition if he wants to do this. However, given that this is the default in gdb too, I am not sure if it is such a good idea to change it. As this problem is specifically about the behavior of process attach, maybe the problem should be solved at a higher level? Could we make "process attach" never set the "crashed" flag? Attaching to a process just at the moment it is about the crash is very unlikely, and I suspect it is actually impossible (on linux at least).

Alternatively, (and this is something that would be useful in in (lit) tests too), we could add a mechanism to selectively suppress the stop-on-error behavior. Something like `nohup process attach ` perhaps?


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67776/new/

https://reviews.llvm.org/D67776