Implement qGetTLSAddr for accessing thread pointer and utilises existing facility to calculate TLS variable address (GetThreadLocalData in DYLD).
A tiny quibble: GetThreadPointer seems like it should return a pointer to the thread that has this register set. I would not guess it's a pointer to the Thread's local storage. Maybe GetThreadLSPointer + a doc string saying what it does would clear this up?
There's one thing that's not clear to me about this patch. What is the relationship between qGetTLSAddr, as implemented here, and its implementation in GDB? I guess they're not compatible since we're not sending or using the offset and link map fields, but it's not clear to me whether we're at least implementing some subset of gdb functionality (e.g., what would gdbserver do if it received one of the packets that we're sending here). If we're not, then I don't think we should be using the same packet for this purpose.
How is this related to the rest of the patch?
I'm not sure what these marks are (tabs maybe), but could you figure out how to revert them?
|114–117 ↗||(On Diff #496655)|
Is this necessary, given that the function is already stubbed out in NativeRegisterContext?
|85 ↗||(On Diff #496655)|
Return llvm::Expected<addr_t> perhaps?
Any reason to not use the PtraceWrapper function?
Might as well not bother parsing them, if they're going to be thrown away anyway.
|1651–1653 ↗||(On Diff #496655)|
Could this be implemented in ThreadGDBRemote directly (without going through the GDBRemoteRegisterContext)?