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 On Jun 18, 2013, at 9:58 AM, Greg Clayton <[email protected]> wrote: > 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 ¬ify, bool &stop, bool > &suppress); > > bool > SBProcess::SetUnixSignalSettings (int signo, bool notify, bool stop, bool > suppress); > > > On Jun 18, 2013, at 1:57 AM, Russell Harmon <[email protected]> wrote: > >> 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? >> >> -- >> Russell Harmon >> >> >> On Mon, Jun 17, 2013 at 11:27 AM, Greg Clayton <[email protected]> wrote: >> Doesn't look like it. Feel free to propose a new API for SBProcess. >> >> On Jun 16, 2013, at 5:27 AM, Russell Harmon <[email protected]> wrote: >> >>> Is there currently a way to configure LLDB's signal disposition via it's >>> API? I'm not seeing a way. >>> -- >>> Russell Harmon >>> _______________________________________________ >>> lldb-dev mailing list >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> >> > > _______________________________________________ > lldb-dev mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
