[rust-dev] morestack prologue contains broken machine code

Vladimir Pouzanov farcaller at gmail.com
Fri Apr 25 08:14:00 PDT 2014


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 <alex at 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 <farcaller at 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/llvm or
> send
> > it to upstream?
> >
> >
> > On Mon, Apr 21, 2014 at 6:34 PM, Vladimir Pouzanov <farcaller at 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 <alex at 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 <
> farcaller at 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 at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140425/a2a0e1d8/attachment.html>


More information about the Rust-dev mailing list