Support for #[thread_local]? about rp-hal

[jsgf]

I've been using @cbiffle's lilos executor for my projects. It's strictly single core but there's no reason why you couldn't run two instances, one on each rp2040 core. It relies on static vars for some of its state so I was thinking that thread local would allow two instances to coexist in ram while sharing code.

Otherwise I'd have to work out how to link in two instances with their own statics which would be annoyingly redundant.

This specific case doesn't seem all that niche, esp since 'static lifetime data is so useful for DMA and such.

[9names]

It would be useful to be able to use #[thread_local] to have functionally static variables which are per-core on rp2040.

I'm having trouble coming up with a use-case where thread_local variables would provide a benefit, what did you have in mind?

[jsgf]

Whatever the mechanism, the rp2040_hal::multicore APIs would need to be extended to expose how much per-thread memory is needed, to allow callers to provide suitable memory when spawning on a new core.

Actually thinking about it, we could just statically allocate bss spaceat link time for the per-thread of for each core, and make this completely transparent to users.