Is there any good reason why kSplitStackAvailable is hard-coded to 256 (given that I have tasks with their whole stack on 512 bytes)? I guess, this constant should actually be externally configurable.
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
