[PATCH] ARM and Thumb Segmented Stacks

[Tim Northover]

Hi Alex,

> According to our initial pull request [1], it sounded like the Thumb
> support was specifically targeting not using a coprocessor for the
> stack limit. It sounds like the stack limit can be in any number of
> locations, and it should have some configuration which dictates how
> you find it. Do you think this configuration should be added, and if
> so, what would be the best way to do that?

I think I'd suggest another call, given the wide range of solutions
that seem to be in use (3 so far). By definition you're already adding
__morestack, so why not __stacklimit too?

If you *can* do this, it would calm another of my worries too: that
there seems to have been a fairly arbitrary decision to nick one of
bionic's TLS slots. Baking that decision into the compiler feels a bit
sketchy, but a runtime can change it at will if bionic either comes up
with its own solution or starts using that slot for its own reasons.

> The x86 implementation at least specifically re-aligns the stack
> before doing anything else (calling the stack allocation function).

It's also occurred to me that when control comes back from __morestack
it's put an entirely new stack in place anyway, so I think I was
rather overzealous here. I'm happy with pushing just lr.

> I agree that for speed this should probably stick to only pushing 2
> regs at the beginning of the function, but I've changed this to using
> "bx" instead of "mov.

Thanks, that sounds fine. Actually, I've realised the call(s) should
be "blx" rather than "bl" for similar reasons.

Cheers.

Tim.