[PATCH] Segmented stack support ARM iOS

[Valerii Hiora]

Hi Tim,

We've checked with some people in here, and both the entire static range
> and the implementation of the pthread_getspecific functions themselves are
> reserved. User code shouldn't be relying on either.
>

 I see. This is exactly why I'm trying to address it earlier and tried to
get Apple attention and approval.

 Is there a chance that Apple will reserve or re-purpose one of existing
slots for segmented stacks like for it did it for Sj/Lj exception handling
(see __PTK_LIBC_DYLD_Unwind_SjLj_Key)? It might be useful for all
LLVM-based compilers and will provide consistency and correct work for code
calling functions compiled by another tool (if it is not a part of official
LLVM, they might have own implementations and steal different slots)

 The only moving part in this case will be implementation of
pthread_getspecific_direct.

  It will also solve the problem for X86 frame lowering (right now it uses
the same trick and silently steals slot #90, which is reserved to
JavaScriptCore)

  This issue is actually not directly LLVM related so feel free to let me
know if we should discuss it elsewhere.

I still personally think the only portable solution is a generic callback.
> If the performance impact of that is too great


It is, considering it is a prologue for every function call.


> we should be trying to come up with a solution that doesn't involve
> importing every platform under the sun's OS-specific code into FrameLowering
>

I'd be glad to implement any but have no idea yet how that could be
achieved considering a simple callback is too heavy.

Cheers!

-- 

  Valerii

On Thu, May 8, 2014 at 12:22 PM, Tim Northover <tnorthover at apple.com> wrote:

> Hi Valerii,
>
> > To be precise, it uses Apple-specific implementation of
> _pthread_{get,set}specific_direct taken from
> http://www.opensource.apple.com/source/Libc/Libc-825.40.1/pthreads/pthread_machdep.hand uses static key #149.  While it is not in Apple-reserved range (0..119
> as of libc 825.40.1), it still unclear if it is smaller than total count of
> reserved slots.
>
> We've checked with some people in here, and both the entire static range
> and the implementation of the pthread_getspecific functions themselves are
> reserved. User code shouldn't be relying on either. Since they're liable to
> change at any point, this would probably block any program that made those
> assumptions from the App Store.
>
> I still personally think the only portable solution is a generic callback.
> If the performance impact of that is too great, we should be trying to come
> up with a solution that doesn't involve importing every platform under the
> sun's OS-specific code into FrameLowering (an already very sensitive area
> of the ARM target: I think most of the bugs I've personally introduced to
> LLVM have been there).
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140508/dc3e9a6e/attachment.html>