[Lldb-commits] [PATCH] D126259: Add the ability to specify signal actions (pass, stop or notify) for a signal before a process is created

[Jim Ingham via Phabricator via lldb-commits]

jingham created this revision.
jingham added reviewers: JDevlieghere, labath, chaoren, clayborg, kastiglione.
Herald added a project: All.
jingham requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

One of the weaknesses of the signal handling model in lldb is that we access the information about signals from the process.  That's good, since different OS'es and even different OS versions might have more or fewer signals, or they may be renumbered, etc.

However, it means you can't set signal handling behaviors in your .lldbinit, and if you set them in one run they don't persist on re-run.  That's been somewhat annoying over the years.

This adds a "DummySignals" map to the target that holds signals as std::strings, and the user intentions.  I called them DummySignals because if you set them in an .lldbinit, they will go into the Dummy Target, and then will prime new targets.  They work like all the other Dummy Target elements, if you add a handling with no Targets, they go to the dummy target then to your target.  If you add them when there's a real target, it will only go into that target.

Just like before, if you run `process handle` when you have a process, the UnixSignals values will be changed, but the change will also be recorded in the DummySignals map so we can apply it on re-run.

I also added a `-c` option to "process handle" which allows you to clear the setting from your target (and with `-d` from the dummy target).
I also added a `-t` option to "process handle" to show you just the changes you made to the default setting values.

Since I wanted you to also  be able to "reset to the default" I had to change the UnixSignals class so it recorded the default value as well as the current value.

There are a couple of pieces of this that aren't done yet, but the patch was getting pretty big.

1. No SB API.  I'll add an SBTarget::HandleSignal to set the handling in the dummy target.
2. When you add a signal with no process, we can't spell-check the signal name for you.  The current patch emits a warning on Launch or Attach if there was a signal whose handling is configured but the signal name wasn't recognized.

I don't plan to do #2 right now.  You would have to have the AddSignal add the signal name to a global pool, and then construct all the Platforms and get them to make their UnixSignals so the registry would happen.  Then you could compare the signal against this list.

I'm not even sure that being able to spell check the signals is worth having to construct all the platforms to build this registry.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126259

Files:
  lldb/include/lldb/Target/Target.h
  lldb/include/lldb/Target/UnixSignals.h
  lldb/packages/Python/lldbsuite/test/lldbutil.py
  lldb/source/Commands/CommandObjectProcess.cpp
  lldb/source/Commands/Options.td
  lldb/source/Target/Process.cpp
  lldb/source/Target/Target.cpp
  lldb/source/Target/UnixSignals.cpp
  lldb/test/API/commands/process/handle/Makefile
  lldb/test/API/commands/process/handle/TestProcessHandle.py
  lldb/test/API/commands/process/handle/main.cpp
  lldb/test/API/functionalities/signal/raise/TestRaise.py
  lldb/unittests/Signals/UnixSignalsTest.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D126259.431528.patch
Type: text/x-patch
Size: 38418 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20220524/4aeaef84/attachment-0001.bin>