[PATCH] ARM and Thumb Segmented Stacks

[Alex Crichton]

ping

On Fri, Feb 28, 2014 at 10:59 AM, Alex Crichton <alex at crichton.co> wrote:
>> 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).