[PATCH] ARM and Thumb Segmented Stacks

Alex Crichton alex at crichton.co
Tue Mar 11 00:23:30 PDT 2014


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

More information about the llvm-commits mailing list