[PATCH] ARM and Thumb Segmented Stacks

[Alex Crichton]

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

Does this __aebi_read_tp instruction basically do the same thing as
the MRC instruction, which finds the local TLS base address? I suppose
at that point I could lift the linux/android restriction on segmented
stacks. I'm hesitant to land this patch without landing the
optimization to use an instruction instead of a call, so I would want
to explore that as well.

Out of curiosity, what does TP stand for?

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

The relevant line of code is:

   BuildMI(AllocMBB, DL, TII.get(ARM::BL)).addExternalSymbol("__morestack")

I switched BL to BLX, which causes the tests to pass (when updating
"bl __morestack" to "blx __morestack"), but the tests fail when
they're generating objects. They trip an assertion in the
ARMMCCodeEmitter with the message "Unable to encode MCOperand!" (see
the end of https://gist.github.com/9277389).