[PATCH] ARM and Thumb Segmented Stacks

[Tim Northover]

Hi Alex,

> 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.

Hmm. How about going via the generic "TPsoft" pseudo-instruction then?
(And "tTPsoft" for Thumb).

Currently, this always expands to an "__aeabi_read_tp" call, but I
think it would be reasonable to propose a second patch that instead
uses the MRC on v7-Linux (and possibly general v7 gnueabi; we'd have
to ask around for when it's a safe optimisation).

That should get you the efficient MRC when it's right, and some kind
of functional fall-back for the weird old architectures.

>> 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.

Very odd, I can't think of any particular peculiarities for BLX that
aren't present for BL too. Which assertion is triggering?

> 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.

The ARM::BLXi and ARM::tBLXi instructions should be the ones that take
a label rather than an explicit register (tracking implicit liveness
is another matter that we're going to have to think about with this
patch anyway, once the outline is secure).

> 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,

The problem is that the same binary can contain both ARM and Thumb
functions, but there is only one __morestack symbol (barring linker
tricks) which is shared.

Cheers.

Tim.