https://github.com/labath commented:
I think this is a pretty good attempt. Thanks for trying it out. My main problem with it is that I still think that this functionality should be in the platform class. I have a couple of reasons for that: - the platform class is the one who defines the layout of the type, so it makes sense for it to be interpreting it as well - this won't work with the way that live processes work now. Linux process will not get a LinuxSignals object -- they get a [GDBRemoteSignals](https://github.com/llvm/llvm-project/blob/b95ad8eca6ae1ef73b4ee3018b69446995f39353/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp#L2601) instance instead. It should be easier to make live processes work if the interpretation is in the platform class (and the signals object just provides the data). - UnixSignals are used in lldb-server and ValueObject is too high-level for it. Having UnixSignals depend on that might explode the dependency tree of lldb-server Basically, what I'm imagining is to take the function you've written here (GetSignalDescriptionFromSiginfo) and put that into the platform class instead -- plus or minus some interface tweaks (I'd consider having the function return a full-blown StopInfo object instead of just a description). https://github.com/llvm/llvm-project/pull/140150 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
