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'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?
--
WBR, Peter Zotov.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
