[rust-dev] TLS for bare-metal targets

Daniel Micay danielmicay at gmail.com
Sun Mar 9 09:48:03 PDT 2014


On 09/03/14 11:11 AM, Peter Zotov wrote:
> Greetings, fellow rustaceans!
> 
> I'm quite interested in having a proper Rust runtime on bare-metal
> targets (specifically ARM Cortex-M at this point). 'Proper', in my
> view, includes having support for such things as thread-local
> variables and stack overflow checking.
> 
> Unfortunately, LLVM emits instructions relevant to fetching
> thread-local data via a switch over target triple and several chunks
> of hardcoded assembly. Of course, that assembly is highly OS-specific;
> as far as I know, only Linux, Windows and Android are supported today.
> 
> I propose to add a set of simple, generic hooks for LLVM to use,
> initially to Rust's LLVM fork, eventually to be upstreamed.

I don't think we should add any more patches. The work should be done
upstream, so that there's upstream input for the whole process. It's not
an issue only relevant to Rust.

> I'm assuming everywhere that linking happens via ELF, because LLVM
> doesn't currently support anything else for interesting targets and
> to my best knowledge, it's true in general. (Correct me if I'm wrong.)
> 
> 1) Give a specific meaning to OS "none" in the target triple.
> Currently "none" does not have any meaning to either LLVM or Rust.
> Under this proposal, "none" would trigger the behavior below.
> 
> 2) All symbols marked with thread_local attribute would be emitted
> to the section .tdata (as they are now). A compatible RTOS would use
> that section to determine the size (via standard linker script magic)
> and initial contents of relevant data blocks allocated per-thread.
> 
> 3) When faced with a requirement to look up a thread-local variable,
> LLVM would load address of the thread-local variable block from
> a mutable global "__tls" (instead of FS-based addressing on x86, etc),
> then proceed as usual.
> 
> 4) When faced with a requirement to look up the stack limit,
> LLVM would load it from a mutable global "__stack_limit". If an existing
> RTOS already has stack limit accessible in some kind of task descriptor,
> and has a static global pointing to current task descriptor, it would
> be possible to make the __stack_limit symbol an alias. Otherwise,
> an RTOS would need to update that global at each context switch, which
> isn't too bad either.
> 
> Unfortunately, the most popular RTOS, FreeRTOS, only has top of stack
> and bottom of stack accessible in its task control block, so this
> scheme won't work out of the box with FreeRTOS.
> 
> I'll implement all the required LLVM machinery for at least ARM
> (it's not target-specific but the relevant code is part of target
> lowering...),
> but first I really hope to hear some feedback from the community.
> Did I miss anything?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140309/8a53a90e/attachment.sig>


More information about the Rust-dev mailing list