[Lldb-commits] [lldb] [LLDB][ProcessELFCore] Add Description to ProcessELFCore/ELFThread stop reasons (PR #110065)

[Pavel Labath via lldb-commits]

================
@@ -76,14 +76,19 @@ static_assert(sizeof(ELFLinuxPrStatus) == 112,
               "sizeof ELFLinuxPrStatus is not correct!");
 
 struct ELFLinuxSigInfo {
-  int32_t si_signo;
-  int32_t si_code;
+  int32_t si_signo; // Order matters for the first 3.
   int32_t si_errno;
+  int32_t si_code;
+  lldb::addr_t addr; /* faulting insn/memory ref. */
----------------
labath wrote:

I'm going to have to disagree with Greg here. The internal layout of `siginfo_t` differs even for different linux architectures, so I don't think that matching any one particular system is doing to be helpful. Matching the exact layout also still wouldn't let us write things like `our_siginfo.si_addr` as that depends on the host macro, which will not be defined everywhere. (And it also would require using reserved identifiers)

 The public interface (`si_addr`), is the same everywhere, so matching that would be better. Now, we can't use that name exactly, as it is a macro, but I we can use something that's closer to it. I'd suggest `si_addr_`, with a small comment that the other name is a macro.

Another thing I'd add here is that we now have (as in, we did not have it when this class was originally written), a way to get the siginfo_t definition precisely matching the os/architecture of the core file -- via `Platform::GetSiginfoType()`. I wouldn't say it's a requirement for this patch, but if you find yourself needing to match the exact layout of a siginfo struct, that's definitely the way I'd recommend. Since this is a `CompilerType`, it will take some refactoring to make it work with the code here, but the nice thing about it is that, once you have everything wired up, you will be able to dump the signal information for a thread with the `thread siginfo` command -- even if you don't have any debug information for the core file.

https://github.com/llvm/llvm-project/pull/110065