[PATCH] ARM and Thumb Segmented Stacks

[Alex Crichton]

ping?

On Tue, Mar 11, 2014 at 12:23 AM, Alex Crichton <alex at crichton.co> wrote:
> 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).