Update the SIGTRAP handler to account for the possibility of SIGTRAP
being generated by the user, i.e. not having any specific debugging
event associated with it, as well as receiving unknown SIGTRAPs. These
instances of SIGTRAP are passed to the regular signal handler.
Details
Diff Detail
Event Timeline
I propose to filter all user induced signals at once and check & 0x10000 and SI_USER.
http://src.illumos.org/source/xref/freebsd-head/sys/sys/signal.h#406
This way we will avoid all future fallout and crashing the debugger on unknown signal.
Updated to treat generic SIGTRAP as a fallback as requested by @krytarowski. This happens either if si_code >= SI_USER, or there is no siginfo and no other flag is set.
lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp | ||
---|---|---|
287 | What will happen in case this returns? Will the process auto-resume or just hang stopped? It sounds like it would still be useful to report this as "SIGTRAP" even if we are unable to give any details about it... |
lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp | ||
---|---|---|
287 | Good catch. Should it be reported as an arbitrary SIGTRAP then or maybe as a trace trap? |
lldb/source/Plugins/Process/FreeBSDRemote/NativeProcessFreeBSD.cpp | ||
---|---|---|
287 | I don't have a strong opinion there. I'd probably just go with a regular SIGTRAP. |
What will happen in case this returns? Will the process auto-resume or just hang stopped? It sounds like it would still be useful to report this as "SIGTRAP" even if we are unable to give any details about it...