0

I previously asked this question, and discovered that lldb will not passthough the data from the siginfo_t struct from the original signal; everything is 0'd out except the signal number. The signals and data in siginfo_t work as expected when the program is not being debugged.

I'm using the process handle subcommand in lldb to ensure passthough is enabled for SIGTERM but this doesnt seem to work (or at least not as I expect). I dont know if this applies to all signals, but I'm specifically interested in SIGTERM.

Is this a bug in lldb? Is there a way to control this behavior? I see nothing in the help.

I'm on macOS 10.14.1 (Mojave) and Xcode 10 (lldb-1000.11.37.1) if that matters.

Brad Allred
  • 7,323
  • 1
  • 30
  • 49

1 Answers1

2

lldb can't directly invoke your signal handler. There isn't a "signals.h" way that I know of on MacOS for one process to send a signal including the targeted thread and any other info to another process. All the pthread_kill variants are local process only.

Instead, the debugger intercepts the signal prior to its actual delivery by getting an EXC_SOFTWARE/EXC_SOFT_SIGNAL Mach exception. Then on resume, it tells the kernel to propagate the signal with the ptrace system utility - using "PT_THUPDATE". That define is in usr/include/sys/ptrace.h. With PT_THUPDATE, you send the signal number and the kernel treats it as if the original signal was suppressed, and a new signal raised.

This process is lossy. Initially, lldb only receives the signal number and the targeted thread, and not any of the other information. Also, PT_THUPDATE API only takes a thread ID and a signal number. So we have no way to forward more info even if we had it.

The kernel would have to keep all the other info around and when lldb forwards the signal, copy it over, or provide API's for lldb to fetch and resend this info along with the signal.

Jim Ingham
  • 25,260
  • 2
  • 55
  • 63
  • 1
    I don't doubt that you are correct, but would you mind linking any official documentation? something on this API it is using? I dont understand why lldb couldnt simply copy the `siginfo_t` from its signal handler and transplant it when it invokes mine? why must the kernel do something special? – Brad Allred Dec 06 '18 at 00:18
  • lldb doesn't "invoke your signal handler". There isn't a "signals.h" way that I know of on MacOS for one process to send a signal including the targeted thread and any other info to another process. All the pthread_kill variants are local process only. – Jim Ingham Dec 06 '18 at 19:54
  • Instead, lldb intercepts the signal - but no siginfo - by getting an EXC_SOFTWARE/EXC_SOFT_SIGNAL Mach exception. Then on resume, it tells the kernel to propagate the signal using the ptrace system utility - using "PT_THUPDATE". That define is in usr/include/sys/ptrace.h. Like with many API's the debugger uses, these are documented in the kernel sources. With PT_THUPDATE, you just send the signal number and the kernel treats it as if the original signal was suppressed, and a new signal raised. – Jim Ingham Dec 06 '18 at 20:01
  • Thank you for the explanation. Accepted. I do think that your last comment should be moved to the answer, however. – Brad Allred Dec 06 '18 at 21:13