clayborg added a comment.
So the "process handle" command allows us to set signals by signal number as
well. Does this patch support this? It seems like it wouldn't be too hard to do
if we wanted to handle this. Lemme know what you think, other than that LGTM.
================
Comment at: lldb/include/lldb/Target/Target.h:1421
+protected:
+ struct DummySignalValues {
+ LazyBool pass = eLazyBoolCalculate;
----------------
jingham wrote:
> clayborg wrote:
> > We should make UnixSignals::Signal a public class and then just save a
> > std::vector of those inside this class. That class doesn't contain a signal
> > number, so we should be able to re-use it here and avoid creating a new
> > class that mimic what is contains.
> The data structure held by the target is different from the one that
> represents actual signals because the Target one needs to record not just
> "true or false" but "whether set by the user." That's why I used LazyBools
> not bools in the structure. That's important because if you are setting a
> signal handling in the .lldbinit you don't yet know what the default value
> is, so you need to be able to say "change print to false, and leave the
> others at their default values".
>
> So I don't think that the UnixSignals::Signal is the right data structure of
> rthis.
Makes sense.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D126259/new/
https://reviews.llvm.org/D126259
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
