Ignoring Signals via the API

Is there currently a way to configure LLDB’s signal disposition via it’s API? I’m not seeing a way.

I see the same. It looks like it's command line only at the moment.

Matt

Doesn't look like it. Feel free to propose a new API for SBProcess.

I’m currently thinking wrapping the UnixSignals object into an SBUnixSignals, or would you prefer an API in SBProcess which is restricted to only ShouldNotify, ShouldStop and ShouldSuppress?

I would think keeping it simple with accessor functions on SBProcess would be the way to go. We should be able to read the current settings for each signal, and set them. Maybe something like:

bool
SBProcess::GetUnixSignalSettings (int signo, bool &notify, bool &stop, bool &suppress);

bool
SBProcess::SetUnixSignalSettings (int signo, bool notify, bool stop, bool suppress);

Actually, I prefer to have an SBUnixSignals class that you get from the SBProcess and poke. The reason for that is that we also need to provide a way to get and manipulate the default settings for signal handling. The way that makes sense to me is that the Platform object should provide the set of signals for that platform. The platform represents the OS on which processes are going to run, and that is the one that knows what signals are supported for processes on that platform, etc.

Note that we have an lldb_private::Platform, but don't have an SBPlatform yet. You can set the default platform through the SBDebugger, but that's about all. This is definitely an area that will need fleshing out, but that's not necessary to get access to the current process's settings from the SB API. It's just useful for thinking about overall design.

Anyway, ultimately we should get the default signal handling object from the platform, and maybe modify it and store that away. Then new processes will inherit that set of default signals. But you also want to go to an individual process and modify its signal handling without changing the default ones. So you will also want to get and set the options from a process. Rather than adding the same set of API's to the SBProcess and the (not yet existing at the SB API layer) SBPlatform, it would make more sense to have an SBUnixSignals object that you could get from either place and query & set directly.

Note, once this is all wired up at the command level we should probably switch from "process handle" to setting the signal handling using the "settings set" commands. That is the way we do general persistent settings. But that's beyond the scope of what Russell was signing up for...

Jim

Two points here:

  1. we should probably have an API to do that - the fact that we don’t is an omission from our API that we need to fix
  2. in the meantime, you can always grab an SBDebugger and pass the appropriate commands down to LLDB with HandleCommand("…")