On Wed, 2022-01-12 at 11:22 -0800, Jim Ingham wrote: > > > On Jan 12, 2022, at 4:28 AM, Pavel Labath <pa...@labath.sk> wrote: > > > > I kinda like the cleanliness (of the design, not the implementation) of a > > $siginfo variable, but you're right that implementing it would be tricky (I > > guess we'd have to write the struct info the process memory somewhere and > > then read it back when the expression completes). > > > > I don't expect that users will frequently want to modify the siginfo > > structure. I think the typical use case would be to inspect the struct > > fields (maybe in a script -- we have one user wanting to do that) to > > understand more about the nature of the stop/crash. > > > > With that in mind, I don't have a problem with a separate command, but I > > don't think that the "platform" subtree is a good fit for this. I mean, I > > am sure the (internal) Platform class will be involved in interpreting the > > data, but all of the platform _commands_ have something to do with the > > system as a whole (moving files around, listing processes, etc.) and not a > > specific process. I think this would belong under the "thread" subtree, > > since the signal is tied to a specific thread. > > Platform seemed appropriate to me because this is a platform specific > feature; some platforms don’t support siginfo at all…. But I’m fine with > thread too. > > > > > Due to the scripting use case, I am also interested in being able to > > inspect the siginfo struct through the SB API -- the expression approach > > would (kinda) make that possible, while a brand new command doesn't > > (without extra work). So, I started thinking whether this be exposed there. > > We already kinda expose the si_signo field via GetStopReasonDataAtIndex(0) > > (and it even happens to be the first siginfo field), but I don't think we > > would want to expose all fields in that manner. > > > > Why not something like: > > SBValue > SBThread::GetSiginfo(); > > That returns an SBValue with the siginfo type and the data filled in from the > gdb-remote packet. If the platform didn’t support this you’d just get an > SBValue with the error set saying “not supported” or whatever. > > If you have all the types of the members to hand it’s easy to cons up an > SBValue from the data you got from the stub. An SBValue is exactly what > you’d get back from the expression parser anyway, so from the client’s > perspective this would be just as good. And printing the SBValue and doing > logic on its members are all well supported. > > If we can’t always get our hands on the siginfo type, we will have to cons > that type up by hand. But we would have had to do that if we were > implementing this feature in the expression parser anyway, and we already > hand-make types to hand out in SBValues for a bunch of the synthetic child > providers already, so that’s a well trodden path. > > You could even make a ValueObjectSiginfo to back the SBValue you hand out > which implements “SetValueFromCString” through the gdb-remote protocol > interface, so writing back to the siginfo through this interface would be > natural. >
Well, it all makes sense to me. It should also make the implementation somewhat easier, as I can focus on getting siginfo_t parser with unit tests first, and then work on the additional commands. -- Best regards, Michał Górny _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
