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
