[lldb-dev] RFC: siginfo reading/writing support

[Michał Górny via lldb-dev]

On Wed, 2022-01-12 at 11:22 -0800, Jim Ingham wrote:
> 
> > On Jan 12, 2022, at 4:28 AM, Pavel Labath <pavel at 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