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/llvm or send it to upstream? On Mon, Apr 21, 2014 at 6:34 PM, Vladimir Pouzanov <[email protected]>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 <[email protected]> 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 <[email protected]> >> 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 >> > [email protected] >> > https://mail.mozilla.org/listinfo/rust-dev >> > >> > > > > -- > Sincerely, > Vladimir "Farcaller" Pouzanov > http://farcaller.net/ > -- Sincerely, Vladimir "Farcaller" Pouzanov http://farcaller.net/
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
