[LLDB] Add SI_USER and SI_KERNEL to Linux signals

[Jlalond]

@dmpots and I were investigating a crash when he was developing LLDB earlier. When I loaded the core I was surprised to see LLDB didn't have information for the SI_CODE. Upon inspection we had an si_code of 128, which is the decimal of SI_KERNEL at 0x80.

These were overlooked in my last addition of the negative si_codes, and this patch adds SI_USER and SI_KERNEL to the list, covering us for all the codes available to all signals.

Linux reference link

I kept the code naming the same as what is defined in the Linux source code. SI_KERNEL to my understanding usually indicates something went awry in the Kernel itself, but I think adding that additional detail would not be helpful to most users. @DavidSpickett I'd appreciate your insight into that.

[llvmbot]

@llvm/pr-subscribers-lldb

Author: Jacob Lalonde (Jlalond)

Changes

@dmpots and I were investigating a crash when he was developing LLDB earlier. When I loaded the core I was surprised to see LLDB didn't have information for the SI_CODE. Upon inspection we had an si_code of 128, which is the decimal of SI_KERNEL at 0x80.

These were overlooked in my last addition of the negative si_codes, and this patch adds SI_USER and SI_KERNEL to the list, covering us for all the codes available to all signals.

Linux reference link

I kept the code naming the same as what is defined in the Linux source code. SI_KERNEL to my understanding usually indicates something went awry in the Kernel itself, but I think adding that additional detail would not be helpful to most users. @DavidSpickett I'd appreciate your insight into that.

---

Full diff: https://github.com/llvm/llvm-project/pull/144800.diff

1 Files Affected:

• (modified) lldb/source/Plugins/Process/Utility/LinuxSignals.cpp (+4)

diff --git a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
index 15a77ce227ec5..ef3d2f2f845da 100644
--- a/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
+++ b/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
@@ -65,6 +65,10 @@
 // See siginfo.h in the Linux Kernel, these codes can be sent for any signal.
 #define ADD_LINUX_SIGNAL(signo, name, ...)                                     \
   AddSignal(signo, name, __VA_ARGS__);                                         \
+  ADD_SIGCODE(signo, signo, SI_USER, 0, "sent by kill, sigsend or raise",      \
+              SignalCodePrintOption::Sender);                                  \
+  ADD_SIGCODE(signo, signo, SI_KERNEL, 0x80, "Sent by kernel",                 \
+              SignalCodePrintOption::Sender);                                  \
   ADD_SIGCODE(signo, signo, SI_QUEUE, -1, "sent by sigqueue",                  \
               SignalCodePrintOption::Sender);                                  \
   ADD_SIGCODE(signo, signo, SI_TIMER, -2, "sent by timer expiration",          \

[labath]

SI_KERNEL to my understanding usually indicates something went awry in the Kernel itself

If by that you mean "a kernel bug" then the answer is no. It's really a catch-all code for signals originating from inside the kernel. Looking at the sources, it looks like this may be sent in case there's a problem with the page tables (which would be a kernel bug or a hardware issue), but it's also used for things like "insufficient space to set up a signal handler frame" (which is definitely an application issue) and "IO on fd is possible (and application did not request a specific signal to be sent)" (which isn't an issue at all).

[DavidSpickett]

Depending on the user's knowledge of / interpretation of how signals work, I don't think "sent by kernel" is enough for them to find their specific problem.

Asking my nearest totally accurate AI model:

Yes, when an application receives a SIGILL (illegal instruction) signal, it is sent by the kernel.

And you can argue this is just the implementation of signals, not the way applications are supposed to think about it, but I think it's one a lot of people would subscribe to.

What you're saying here is that the cause of the generation of the signal (by whomever generates it), was located in a certain place. So the place that tried to execute the illegal instruction, not the place that wrapped up that exception data into a signal.

It's crude but maybe just include SI_KERNEL in there? "sent by kernel (SI_KERNEL)". Then we don't have to explain the meaning of SI_KERNEL but I the user do have something I can look up and read about it. And if they do have a kernel side problem, doing some reading is what they'll need to do anyway.

[Jlalond]

It's crude but maybe just include SI_KERNEL in there? "sent by kernel (SI_KERNEL)". Then we don't have to explain the meaning of SI_KERNEL but I the user do have something I can look up and read about it. And if they do have a kernel side problem, doing some reading is what they'll need to do anyway.

As @labath mentioned there are a lot of things that could cause this. So I think the crude approach is the right one! I've updated the patch.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.