AFAIK, it's emulated in software with __tls_get_addr. Mind that Cortex-M MCUs that I'm toying with aren't usually compatible with any "full-blown" OS, and all the RTOSes out there have different implementations of multithreading and TLS, utilising the "none" OS target of gcc. The best way to deal with this would be to specify "arm-none-eabi" ABI for llvm, that would include tls behaviour amongst other things, but that sounds like a very complex task.
On Fri, Apr 25, 2014 at 5:20 PM, Alex Crichton <a...@crichton.co> wrote: > The prologue is run on every single function executed in a program, so > I believe that in the hopes of keeping it as light as possible it > never makes any function calls. > > I do agree though, that it's at tricky situation in that case. How > does TLS otherwise work for that platform? > > On Fri, Apr 25, 2014 at 8:14 AM, Vladimir Pouzanov <farcal...@gmail.com> > wrote: > > I have a side question related to the same code. > > > > Currently __STACK_LIMIT is constant, but I would like the preamble to > verify > > stack overflow for multithreaded context, i.e. __STACK_LIMIT will depend > on > > the current running thread. Is there any reason, why it's not a function? > > Any objections if I do some refactoring and make it a function? For a > simple > > case that could be a weak symbol that returns a constant. > > > > > > On Tue, Apr 22, 2014 at 9:00 AM, Alex Crichton <a...@crichton.co> wrote: > >> > >> I agree with Corey, it's much better to send it upstream first. I'd be > >> more than willing to help you out with writing tests or taking a peek > >> at the patch if you want! I'm acrichto on IRC > >> > >> On Tue, Apr 22, 2014 at 12:43 AM, Vladimir Pouzanov < > farcal...@gmail.com> > >> wrote: > >> > The problem is that mrc is generated unless target is thumb1, but > >> > cortex-m3 > >> > is thumb2 that still doesn't support mrc: > >> > > >> > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka398.html > , > >> > so an additional check to ST->TargetTriple.Data is required to verify > >> > it's > >> > not thumbv7m. > >> > > >> > Do I need to submit patch against https://github.com/rust-lang/llvmor > >> > send > >> > it to upstream? > >> > > >> > > >> > On Mon, Apr 21, 2014 at 6:34 PM, Vladimir Pouzanov < > farcal...@gmail.com> > >> > wrote: > >> >> > >> >> Hm, it seems to have precautions to stop mrc from materializing on > >> >> Thumb1. > >> >> I guess I need to take a better look into what's going wrong on my > >> >> side. > >> >> I'll see what I can do with that. > >> >> > >> >> > >> >> On Mon, Apr 21, 2014 at 5:23 PM, Alex Crichton <a...@crichton.co> > >> >> wrote: > >> >>> > >> >>> The split stack patches for ARM were recently upstreamed, and they > >> >>> were modified when being upstreamed as well. Primarily the location > of > >> >>> the split stack is no longer at a magic address for thumb, but > rather > >> >>> it uses the same instruction as ARM (some thumb processors do indeed > >> >>> have the coprocessor). More information is in the long thread > starting > >> >>> at the initial attempt to upstream [1]. > >> >>> > >> >>> For now you'll have to use no_split_stack because the thumb split > >> >>> stack will always use a coprocessor, but I'm sure that the upstream > >> >>> LLVM devs would be quite welcoming to tweaks to the slit-stack > support > >> >>> (I'd also be willing to help). You can find the initial commit for > >> >>> support at rust-lang/llvm [2]. > >> >>> > >> >>> [1] - > >> >>> > >> >>> > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140224/205968.html > >> >>> [2] - https://github.com/rust-lang/llvm/pull/4 > >> >>> > >> >>> On Mon, Apr 21, 2014 at 6:50 AM, Vladimir Pouzanov > >> >>> <farcal...@gmail.com> > >> >>> wrote: > >> >>> > Starting recently (no more than two weeks), rustc is generating a > >> >>> > broken > >> >>> > prologue for arm. Here's the sample assembly: > >> >>> > 0x00000f44 <+0>: push {r4, r5} > >> >>> > => 0x00000f46 <+2>: mrc 15, 0, r4, cr13, cr0, {3} > >> >>> > 0x00000f4a <+6>: mov r5, sp > >> >>> > 0x00000f4c <+8>: b.n 0xa78 <main+2616> > >> >>> > 0x00000f4e <+10>: ands r4, r0 > >> >>> > 0x00000f50 <+12>: cmp r4, r5 > >> >>> > 0x00000f52 <+14>: bcc.n 0xf66 > >> >>> > > >> >>> > > >> >>> > > <_ZN7drivers3lcd6c1233244C12332$LT$$x27a$C$$x20S$C$$x20T$GT$.lcd..LCD5flush20h76589116290686712394v0.0E+34> > >> >>> > 0x00000f54 <+16>: movs r4, #16 > >> >>> > 0x00000f56 <+18>: movs r5, #0 > >> >>> > 0x00000f58 <+20>: push {lr} > >> >>> > 0x00000f5a <+22>: bl 0x19d8 <__morestack> > >> >>> > 0x00000f5e <+26>: ldr.w lr, [sp], #4 > >> >>> > 0x00000f62 <+30>: pop {r4, r5} > >> >>> > 0x00000f64 <+32>: bx lr > >> >>> > > >> >>> > The problem is at 0x00000f46, where code tries to read from > >> >>> > coprocessor > >> >>> > 15 > >> >>> > register 13, which is "process id register". Well, coprocessor 15 > >> >>> > (actually, > >> >>> > all of the coprocessors) are missing from my target > >> >>> > thumbv7m-linux-eabi > >> >>> > (with added flavour of -Ctarget-cpu=cortex-m3, which should be > >> >>> > redundant > >> >>> > anyway), so I'm getting hardfaults in every function that rust > >> >>> > doesn't > >> >>> > inline. > >> >>> > > >> >>> > Any ideas on what might be going wrong? I assume that this is > >> >>> > actually > >> >>> > llvm's fault, as llvm should not materialize machine code which is > >> >>> > not > >> >>> > available for target anyway. > >> >>> > > >> >>> > Wrapping everything in #[no_split_stack] is a temporary workaround > >> >>> > and > >> >>> > surely not a long-term strategy. > >> >>> > > >> >>> > -- > >> >>> > Sincerely, > >> >>> > Vladimir "Farcaller" Pouzanov > >> >>> > http://farcaller.net/ > >> >>> > > >> >>> > _______________________________________________ > >> >>> > Rust-dev mailing list > >> >>> > Rust-dev@mozilla.org > >> >>> > https://mail.mozilla.org/listinfo/rust-dev > >> >>> > > >> >> > >> >> > >> >> > >> >> > >> >> -- > >> >> Sincerely, > >> >> Vladimir "Farcaller" Pouzanov > >> >> http://farcaller.net/ > >> > > >> > > >> > > >> > > >> > -- > >> > Sincerely, > >> > Vladimir "Farcaller" Pouzanov > >> > http://farcaller.net/ > > > > > > > > > > -- > > Sincerely, > > Vladimir "Farcaller" Pouzanov > > http://farcaller.net/ > -- Sincerely, Vladimir "Farcaller" Pouzanov http://farcaller.net/
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
