diff options
| author | Jacob Lalonde <jalalonde@fb.com> | 2025-05-27 09:13:50 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-05-27 09:13:50 -0700 |
| commit | ff7bb17c88328276323603809d5d4549ca8bd22b (patch) | |
| tree | ef742021ecf72bb3e292d4e4505be50b5ac69d37 /lldb/test/API/python_api/global_module_cache/TestGlobalModuleCache.py | |
| parent | f3b404be973507432cf86c177978d9de708d850c (diff) | |
[LLDB][ELF Core] Support all the Generic (Negative) SI Codes. (#140150)
Recently, I was on an issue that generated a large number of Coredumps,
and every time in both LLDB and GDB the signal was just `SIGSEGV`.
This was frustrating because we would expect a `SIGSEGV` to have an
address, or ideally even bounds. After some digging I found the
`si_code` consistently was -6. With some help from
[@cdown](https://github.com/cdown), we found neither LLDB or GDB
supports the si_codes sent from [user
space](https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/siginfo.h#L185).
Excerpted from the sigaction man page.
```
For a regular signal, the following list shows the values which
can be placed in si_code for any signal, along with the reason
that the signal was generated.
```
For which I added all of the si_codes to every Linux signal. Now for the
Coredump that triggered this whole investigation we get the accurate and
now very informative summary.
<img width="524" alt="image"
src="https://github.com/user-attachments/assets/5149f781-ef21-4491-a077-8fac862fbc20"
/>
Additionally from @labath's suggestion to move this to platform and
leverage the existing `getSiginfo()` call on thread, we can now inspect
the siginfo struct itself via `thread siginfo`. Giving us another
towards GDB parity on elf cores.
Diffstat (limited to 'lldb/test/API/python_api/global_module_cache/TestGlobalModuleCache.py')
0 files changed, 0 insertions, 0 deletions
