[PATCH] ARM and Thumb Segmented Stacks

[Alex Crichton]

>> According to our initial pull request [1], it sounded like the Thumb
>> support was specifically targeting not using a coprocessor for the
>> stack limit. It sounds like the stack limit can be in any number of
>> locations, and it should have some configuration which dictates how
>> you find it. Do you think this configuration should be added, and if
>> so, what would be the best way to do that?
>
> I think I'd suggest another call, given the wide range of solutions
> that seem to be in use (3 so far). By definition you're already adding
> __morestack, so why not __stacklimit too?

Due to the prologue being executed for all function calls, I believe
that by design it strives to not need an extra function call per
function call. On x86/x86_64, special slots in the OS's TCB are
pre-selected by LLVM for the stack limit, and these slots can't change
without modifying LLVM. I think this is just following the same
precedent. I would expect this to be a choice made at compile time
rather than runtime of where the stack limit is located.

>> I agree that for speed this should probably stick to only pushing 2
>> regs at the beginning of the function, but I've changed this to using
>> "bx" instead of "mov.
>
> Thanks, that sounds fine. Actually, I've realised the call(s) should
> be "blx" rather than "bl" for similar reasons.

I'm having a bit of difficulty getting this to compile and run. I can
get it to emit assembly, but it ends up tripping an assertion in the
assembler. I only found one other use case in ARMFastISel, and it
looks like I need a register operand that needs some serious code to
materialize, so I got a little stuck. According to ARM's
documentation, it appears that "blx label" is valid, so I'm a little
confused why a register in play is necessary.

How necessary is it to support switching between arm/thumb modes
though? I would figure that ARM code would use an ARM __morestack
function and Thumb code would use a Thumb __morestack function,