If you're going to do this, it should support FreeRTOS if you actually want the embedded community to play with it. I'd stay away from using one of the proprietary options as the driving platform at a minimum.
On Sun, Mar 9, 2014 at 12:48 PM, Daniel Micay <danielmi...@gmail.com> wrote: > 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? > > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > -- Craig
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
