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



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to