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 > _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
