Starting recently (no more than two weeks), rustc is generating a broken
prologue for arm. Here's the sample assembly:
0x0f44 <+0>: push {r4, r5}
=> 0x0f46 <+2>: mrc 15, 0, r4, cr13, cr0, {3}
0x0f4a <+6>: mov r5, sp
0x0f4c <+8>: b.n 0xa78
0x0f4e <+10>: ands r4, r0
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).
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 wrote:
> The split stack patches for ARM were recently upstreamed,
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 s
Sending it upstream is far better. Ping someone (probably Alex) to
upgrade our LLVM once it's merged.
On Tue, Apr 22, 2014 at 3:43 AM, Vladimir Pouzanov wrote:
> The problem is that mrc is generated unless target is thumb1, but cortex-m3
> is thumb2 that still doesn't support mrc:
> http://infoce
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 wrote:
> The problem is that mrc is generated unless targe
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
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, 20
AFAIK, it's emulated in software with __tls_get_addr. Mind that Cortex-M
MCUs that I'm toying with aren't usually compatible with any "full-blown"
OS, and all the RTOSes out there have different implementations of
multithreading and TLS, utilising the "none" OS target of gcc. The best way
to deal w
I guess I've misread how __STACK_LIMIT works, it seems that I can change
it's value on context switch so that it keeps track of the current running
task. Works flawlessly, so I'm going to proceed with my original patch now.
On Fri, Apr 25, 2014 at 6:33 PM, Vladimir Pouzanov wrote:
> AFAIK, it's
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 wrote:
> The prologue is run on every single fu
11 matches
Mail list logo
