-
Notifications
You must be signed in to change notification settings - Fork 240
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 per-core state using #[thread_local] #794
Conversation
bbf7b2b
to
a8768cb
Compare
- Controlled by `thread_local` feature - Does not require nightly features, but using it does - Intercepts `__pre_init` to copy .tdata into the per-core state - Implements `__aeabi_read_tp` to returns per-core state for code compiler generates when accessing `thread_local` variables - Needs linker script support to set up the layout and symbols This is based on [picolibc](https://github.com/picolibc/picolibc/blob/58d6157cc2135df5043d62c3e89feedc20ffcd57/newlib/libc/picolib/machine/arm/read_tp.S#L71)'s support for TLS; its the only example I found of it for rp2040.
a8768cb
to
be5b9ea
Compare
A few random thoughts:
|
@jannic Thanks for your comments.
There's no problem with doing this in principle. The per-core data has the same semantics as regular static data/bss - it will be in the same state when you re-spawn on the core as it was before. This is a little different from traditional per-thread data, which will be re-initialized each time you start a thread. But I think since the core is a persistent entity, this current behaviour makes sense. That said, it wouldn't be too hard to reinitialize the per-core data on spawn. I don't think there's any additional soundness issues here. If the per-thread/core data is
Will do.
Yeah I was thinking about this. I really just need a hook to initialize the per-core data before the core 0 main comes up. I think it would make sense to add a dedicated hook in the cortex-m-rt startup code for this, since in principle this could apply to any multicore implementation. Otherwise I don't have any great ideas for how to add a chainable __pre_init, unless it's something like ctors.
What's the context here? Are you concerned about this implementation's use of |
For example https://internals.rust-lang.org/t/pre-rfc-deprecate-then-remove-static-mut/20072/106. Or rust-lang/rust#117556. I didn't follow it in detail, so your usage could be unrelated to the planned / discussed changes. |
@jannic I see. The proposal is literally about |
Exactly. And I don't think they'll break existing code, at least not without a long grace period. So using static mut now is not out of question. It's just that I'd prefer to use a different mechanism from the start if we introduce a new feature now. Of course, only if such a mechanism already exists. |
9cb00c9
to
5716506
Compare
- for __eabi_read_tp, simplify to just directly load TLS_CORE_[01] as needed without the need for an indirection. This only uses r0 and doesn't touch the stack. - Write the tdata copy in Rust, being careful to only use raw pointers. The generated asm is functionally identical to the hand-written asm.
FIXME: nightly only
fb3c168
to
5a547d0
Compare
Question: How can I config ci to handle a nightly only feature like this? Aside from that I'm still working on testing so it's not ready for merging. |
We only merge stable compatible code, so it’s not something we really have to deal with. |
Ok so this is in the back burner until thread local is stabilized? I can probably just publish it as a separate crate, since |
OK I've published this functionality as a separate crate: So we can close this for now, and restart the conversation when #[thread_local] is stabilized. |
thread_local
feature__pre_init
to copy .tdata into the per-core state__aeabi_read_tp
to returns per-core state for code compiler generates when accessingthread_local
variablesThis is based on picolibc's support for TLS; its the only example I found of it for rp2040.
Prototype for #793