summaryrefslogtreecommitdiff
path: root/lldb/test/API/python_api/global_module_cache/TestGlobalModuleCache.py
diff options
context:
space:
mode:
authorJacob Lalonde <jalalonde@fb.com>2025-05-27 09:13:50 -0700
committerGitHub <noreply@github.com>2025-05-27 09:13:50 -0700
commitff7bb17c88328276323603809d5d4549ca8bd22b (patch)
treeef742021ecf72bb3e292d4e4505be50b5ac69d37 /lldb/test/API/python_api/global_module_cache/TestGlobalModuleCache.py
parentf3b404be973507432cf86c177978d9de708d850c (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