jingham added a comment. 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. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D108335/new/ https://reviews.llvm.org/D108335 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
