summaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/Process/Utility/LinuxSignals.cpp
AgeCommit message (Collapse)Author
2025-10-15[lldb] Do not stop the process on SIGWINCH by default. (#163182)Ebuka Ezike
SIGWINCH is sent when the terminal window size changes.. Most people debugging do not want the process on this signal. When using lldb-dap, the user may be using an integrated terminal and may resize the pane/window mulitple times when debugging. this causes the signal to be sent multiple times. It gets in the way. The process ignores this signal by default
2025-06-24[LLDB] Add SI_USER and SI_KERNEL to Linux signals (#144800)Jacob Lalonde
@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](https://github.com/torvalds/linux/blob/74b4cc9b8780bfe8a3992c9ac0033bf22ac01f19/include/uapi/asm-generic/siginfo.h#L175) ![image](https://github.com/user-attachments/assets/52fa58e6-13d4-48a1-8d82-184c07a47db8) 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.
2025-05-29Reapply "[LLDB][ELF Core] Support all the Generic (Negative) SI Codes." ↵Jacob Lalonde
(#141670) After some debugging, I found out ProcessELFCore never updates the platform. I've updated ProcessElfCore to set the arch and platform before we parse the Notes.
2025-05-27Revert "[LLDB][ELF Core] Support all the Generic (Negative) SI Codes." (#141645)Jacob Lalonde
Reverts llvm/llvm-project#140150 Broke the Darwin tests, but they pass on Linux. Reverting to make the build healthy while I investigate
2025-05-27[LLDB][ELF Core] Support all the Generic (Negative) SI Codes. (#140150)Jacob Lalonde
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.
2025-04-09[LLDB][MIPS] Fix signal SIGBUS number mismatch error on mips target (#132688)yingopq
Now, because we do not support mips debugging, if we compile LLVM on mips target, would report error `static assertion failed:Value mismatch for signal number SIGBUS`, so add this condition to avoid error.
2025-01-21[lldb][Linux] Add Control Protection Fault signal (#122917)David Spickett
This will be sent by Arm's Guarded Control Stack extension when an invalid return is executed. The signal does have an address we could show, but it's the PC at which the fault occured. The debugger has plenty of ways to show you that already, so I've left it out. ``` (lldb) c Process 460 resuming Process 460 stopped * thread #1, name = 'test', stop reason = signal SIGSEGV: control protection fault frame #0: 0x0000000000400784 test`main at main.c:57:1 54 afunc(); 55 printf("return from main\n"); 56 return 0; -> 57 } (lldb) dis <...> -> 0x400784 <+100>: ret ``` The new test case generates the signal by corrupting the link register then attempting to return. This will work whether we manually enable GCS or the C library does it for us. (in the former case you could just return from main and it would fault)
2023-03-27Revert "[lldb] Move UnixSignals creation into Platform plugins"Alex Langford
This reverts commit ee232506b870ce5282cc4da5ca493d41d361feb3. As discussed in https://reviews.llvm.org/D146668 we'll find another way forward.
2023-03-20[lldb] Move UnixSignals creation into Platform pluginsAlex Langford
The high level goal of this change is to remove lldbTarget's dependency on lldbPluginProcessUtility. The reason for this existing dependency is so that we can create the appropriate UnixSignals object based on an ArchSpec. Instead of using the ArchSpec, we can instead take advantage of the Platform associated with the current Target. This is accomplished by adding a new method to Platform, CreateUnixSignals, which will create the correct UnixSignals object for us. We then can use `Platform::GetUnixSignals` and rely on that to give us the correct signals as needed. Differential Revision: https://reviews.llvm.org/D146263
2023-03-20[lldb] Implement CrashReason using UnixSignalsDavid Spickett
By adding signal codes to UnixSignals and adding a new function where you can get a string with optional address and bounds. Added signal codes to the Linux, FreeBSD and NetBSD signal sets. I've checked the numbers against the relevant sources. Each signal code has a code number, description and printing options. By default you just get the descripton, you can opt into adding either a fault address or bounds information. Bounds signals we'll use the description, unless we have the bounds values in which case we say whether it is an upper or lower bound issue. GetCrashReasonString remains in CrashReason because we need it to be compiled only for platforms with siginfo_t. Ideally it would move into NativeProcessProtocol, but that is also used by NativeRegisterContextWindows, where there would be no siginfo_t. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D146044
2020-10-08[lldb] Format remaining signal table (NFC)Jonas Devlieghere
Restore the signal tables to its original glory and mark it as not to be clang-formatted.
2020-10-08Change the default handling of SIGCONT to nosuppress/nostop/notifyJim Ingham
Except for the few people actually debugging shells, stopping on a SIGCONT doesn't add any value. And for people trying to run tests under the debugger, stopping here is actively inconvenient. So this patch switches the default behavior to not stop. Differential Revision: https://reviews.llvm.org/D89019
2020-01-24[lldb][NFC] Fix all formatting errors in .cpp file headersRaphael Isemann
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-11-11Remove header grouping comments.Jonas Devlieghere
This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. llvm-svn: 346626
2016-09-06*** This commit represents a complete reformatting of the LLDB source codeKate Stone
*** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2015-10-20[LLDB] Insert names with same signo as alias instead of a new entryMohit K. Bhakkad
Reviewers: clayborg, labath. Subscribers: jaydeep, dsanders, bhushan, sagar, nitesh.jain, emaste,lldb-commits. Differential Revision: http://reviews.llvm.org/D13646 llvm-svn: 250801
2015-09-14Switch default disposition of realtime signalsPavel Labath
Summary: Realtime signals generally do not represent an error condition in an application but are more like a regular means of IPC. As such, we shouldn't interrupt an application whenever it recieves one. If any application will use these signals, it will probably use them a lot, rendering it's debugging tiresome if we stopped at every signal. Furthermore, these signals are likely to be used in a low level library, and the programmer may not even be aware of their presence. For these reasons, I am switching the default disposition of realtime signals on all supported platforms (i.e. Linux and Freebsd) to no-stop, no-notify. Any user still wishing to receive these signals can always change the default to suit his needs. Reviewers: ovyalov, emaste Subscribers: lldb-commits, emaste Differential Revision: http://reviews.llvm.org/D12795 llvm-svn: 247537
2015-07-14Refactor Unix signals.Chaoren Lin
Summary: - Consolidate Unix signals selection in UnixSignals. - Make Unix signals available from platform. - Add jSignalsInfo packet to retrieve Unix signals from remote platform. - Get a copy of the platform signal for each remote process. - Update SB API for signals. - Update signal utility in test suite. Reviewers: ovyalov, clayborg Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11094 llvm-svn: 242101
2015-05-22Add real time signals support to LinuxSignalsPavel Labath
Summary: This enables correct handling of real time signals by lldb. Test Plan: Added a test that verifies handling of SIGRTMIN Reviewers: tberghammer, ovyalov Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9911 llvm-svn: 238009
2015-03-31Move several plugin to its own namespaceTamas Berghammer
Affected paths: * Plugins/Platform/Android/* * Plugins/Platform/Linux/* * Plugins/Platform/gdb-server/* * Plugins/Process/Linux/* * Plugins/Process/gdb-remote/* Differential revision: http://reviews.llvm.org/D8654 llvm-svn: 233679
2014-10-31Always transmit SIGPROF back to the inferior.Stephane Sezer
Summary: SIGPROF is used for profiling processes (with google-perftools for instance), which results in the inferior receiving a SIGPROF from the kernel every few milliseconds. Instead of stopping the debugging session and notifying the user of this, we should just pass the signal and keep running. This follows the behavior we have in UnixSignals.cpp. Test Plan: Run LLDB on linux with a binary using google-perftools, see that execution gets interrupted all the time because we receive SIGPROF. Apply the patch, everything works fine. Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D5953 llvm-svn: 221011
2014-06-30Fixup Windows build breaks for the llgs upstream.Todd Fiala
Also moves NativeRegisterContextLinux* files into the Linux directory. These, like NativeProcessLinux, should only be built on Linux or a cross compiler with proper headers. llvm-svn: 212074
2014-06-30Add lldb-gdbserver support for Linux x86_64.Todd Fiala
This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64. (More architectures coming soon). Not every debugserver option is covered yet. Currently the lldb-gdbserver command line can start unattached, start attached to a pid (process-name attach not supported yet), or accept lldb attaching and launching a process or connecting by process id. The history of this large change can be found here: https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64 Until mid/late April, I was not sharing the work and continued to rebase it off of head (developed via id tfiala@google.com). I switched over to user todd.fiala@gmail.com in the middle, and once I went to github, I did merges rather than rebasing so I could share with others. llvm-svn: 212069