Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve
the siginfo value from server.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Add another test using FreeBSD siginfo_t, to make sure we select the platform correctly.
Seems reasonable to me. Jim, do you have any thoughts on this?
lldb/test/API/functionalities/gdb_remote_client/TestGDBRemoteClient.py | ||
---|---|---|
494 | I'd probably factor the out the common parts into a helper fn, as these two tests only differ in constants. |
Add a common test function. Document the raw data. Include trapno check on FreeBSD.
That said, it just occurred to me that I need to add some packet indicating the architecture.
I've forgotten that the architecture is inferred from target here. Added i386 test for completeness.
Update following changes in GetSiginfoType() — notably stop relying on the SBPlatform API and update for new prototype.
lldb/source/API/SBThread.cpp | ||
---|---|---|
1326–1334 | It should be fine to chain these, relying on the fact that the SB methods on an empty object will return another empty object. |
lldb/source/API/SBThread.cpp | ||
---|---|---|
1326–1334 | I suppose I could avoid process and switch to getting byte order from target but tbh I think the explicit error message for lack of process is worth keeping the split. |
We don't return errors separately for any of the API's that return an SBValue. SBValue's carry their error with them (SBValue.GetError()) so it would be confusing to have two errors.
I'm sorry but I can't figure out how to set the error inside SBValue. The only user-facing thing that seems to allow passing Status seems to be ValueObjectConstResult::Create() but it feels like it's not supposed to be used like this (and it doesn't seem to preserve my Status either).
Yes, you probably need to make another change, which is actually probably a good idea as well.
The immediate problem is that the default constructed SBValue is empty, it has a null ValueObjectSP, so until you somehow make it valid you can't get a valid error from it, in which to set your error string. By the time you've made a valid SBValue it's too late.
But I think actually you should fix this by having a
ValueObjectSP lldb_private::Thread::GetSiginfoValue()
then the SB API will just wrap that call. That way you can make a real ValueObject, with a real error, and return that at any stage.
That will fix your problem, but the real reason for doing this is that lldb_private code can't call back into the SB API's. So if anybody in lldb_private land needed the ValueObject that wrapped the Siginfo information, which is after all the handiest form in which to have it, they would be out of luck.
I didn't get a chance to review this, sorry about that. But in general, SB API's should not do any more work than is necessary to marshal the incoming arguments & figure out which lldb_private API to dispatch it to. Otherwise you've written code is going to end up getting duplicated somewhere (in a command or somewhere else it's needed...)
Add Thread::GetSiginfoValue() to perform baseline value construction, and limit SBThread::GetSiginfo() to wrapping that. Return errors via ValueObjectConstResult.
It should be fine to chain these, relying on the fact that the SB methods on an empty object will return another empty object.