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?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
