Page MenuHomePhabricator

[lldb] Move UnixSignals subclasses to lldbTarget
Needs RevisionPublic

Authored by bulbazord on Aug 18 2021, 3:11 PM.

Details

Reviewers
clayborg
jingham
teemperor
JDevlieghere
Group Reviewers
Restricted Project
Summary

I have created this change as a way to solicit feedback and foster
discussion. My goal is to sever lldbTarget's dependence on
lldbPluginProcessUtility as a part of my larger goal of more cleanly
setting boundaries between lldb's core libraries and lldb's plugin
libraries.

For the purposes of concretely demonstrating what severing the
dependence would look like, I made the easiest change possible (moving
files). I don't think this is the right kind of change because
lldbTarget should ideally be platform-independent. I considered turning
UnixSignals into a Plugin, but to me this felt like overkill. I think
the best change may be somewhere else (possibly creating a new non-plugin
library?) but I'm not sure what that should look like.

Feedback is appreciated.

Diff Detail

Event Timeline

bulbazord created this revision.Aug 18 2021, 3:11 PM
bulbazord requested review of this revision.Aug 18 2021, 3:11 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 18 2021, 3:11 PM

I appreciate the aim, but I don't think moving a whole bunch of platform specific files from Plugins/Process/Utility to Target is the right way to go. If anything that's moving platform specific files further up into generic code.

Since the list of valid signals and their numberings are really platform specific, those files should go into their appropriate Platform. Then when lldb needs the signal mapping, it should ask the current target's Platform for the right Signals object, and the platform should hand you that. Since generic code only ever needs the UnixSignals APIs, UnixSignals.h would properly go in include/lldb/Target, but all the other ones would live in their platforms.

The Signals API needs a little reworking. Because the Signals are gotten from the Process, you can't set signal handling till you have a running process. That's annoying because it means you can't configure signal behaviors in your .lldbinit, you have to do it from a breakpoint on main or something dopey like that. The Target really needs to have a general interface that only knows about signals by text name, so it can register the "process handle" settings in the dummy target, propagate them to new Targets which then ask the current UnixSignals object for name -> signal number.

So maybe we should do a UnixSignals object that just has a list of signal names and behaviors. Then it would be the one that "has a" Platform Specific signals object, and uses that both to do name->number lookups for the current platform, and report any operations on signals that aren't supported by the current platform.

jingham requested changes to this revision.Aug 23 2021, 6:13 PM
This revision now requires changes to proceed.Aug 23 2021, 6:13 PM