-
-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support qGetTLSAddr
#63
Comments
Thanks for popping open the issue - always good to know what protocol features folks are interested in! A cursory glance through the protocol docs suggests that this should be a pretty trivial addition, and wouldn't require any breaking API changes. i.e: this can be implemented as a standard IDET. We'd probably want to stick this function in If I had to guess how the user-facing API would look like, I'd wager it'd be something along the lines of: pub trait GetTlsAddr: MultiThreadOps {
...
fn get_tls_addr(
&self,
thread: Tid,
offset: <Self::Arch as Arch>::Usize,
load_module: &[u8], // OS/ABI specific
) -> TargetResult<<Self::Arch as Arch>::Usize, Self>;
} The only open design question is whether or not it'd make sense to try and encode the specific load_module representation as part of the This would add some complexity to the implementation, and also make adding the feature an API-breaking change. That is to say, I'd be fine with keeping things simple for now, and potentially updating the API at some point down the line. Also, as you might be able to tell from the commit history, I am planning on cutting a 0.6 release at some point in the near future. I was hoping to do it by end of June, but life suddenly got in the way, and I haven't found the time to sit back down and push the release over the finish line 😅. That said, it'd be a shame to sit on so many unreleased changes, so hopefully I'll push a release out sometime in the next few weeks... Lastly, as with most |
Thanks for the quick reply! I stumbled upon this while reimplementing GDB support in uhyve, but still have to figure out the details and if it makes sense to have this extension. A TLS extension might be useful for single threaded targets as well, because single threads could still have TLS, could they not? I should be able to have a more detailed look at this in the next weeks and would be happy to push this forward and test this, if it makes sense for our project. |
Yes? But also, I'm not sure if the added complexity to the For context, the whole point of As such, I think we should focus on implementing this for
Yeah, no pressure! Like I said, I'd be happy to review any PRs sent my way 😄
FYI, I don't think the current Notably, the new state-machine based API makes it much easier to poll for Ctrl-C interrupts (i.e: you don't need to periodically wake up the gdbstub thread to check if an interrupt has arrived). |
I see. That makes sense.
Awesome! I will look into that. Thanks for your awesome crate, by the way! I already have a WIP integration using |
Outside of embedded, TLS is still fairly common in single threaded programs due to |
Ahh, this is a fair point. In that case, we should also include an implementation for single threaded targets as well. We'd probably want to take a similar approach to |
I noticed that this crate does not support
qGetTLSAddr
for working with thread-local storage.Although I do not currently need this myself, I thought it would be good to track this issue.
The text was updated successfully, but these errors were encountered: