<div dir="ltr"><div>Hi Tim,<br><br><div class="gmail_extra"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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.<br></blockquote><div><br></div><div> I see. This is exactly why I'm trying to address it earlier and tried to get Apple attention and approval.<br><br> 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)<br>

<br></div><div> The only moving part in this case will be implementation of pthread_getspecific_direct.<br><br></div><div>  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)<br>

</div><div><br></div><div>  This issue is actually not directly LLVM related so feel free to let me know if we should discuss it elsewhere.<br></div>
<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
I still personally think the only portable solution is a generic 
callback. If the performance impact of that is too great</blockquote><div><br></div><div>It is, considering it is a prologue for every function call.<br></div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">

 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<br></blockquote><div><br></div><div> I'd be glad to implement any but have no idea yet how that could be achieved considering a simple callback is too heavy.<br>

<br></div><div>Cheers!<br></div><div><br>-- <br><br></div><div>  Valerii<br></div><br><div class="gmail_quote">On Thu, May 8, 2014 at 12:22 PM, Tim Northover <span dir="ltr"><<a href="mailto:tnorthover@apple.com" target="_blank">tnorthover@apple.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Valerii,<br>
<div class=""><br>
> To be precise, it uses Apple-specific implementation of _pthread_{get,set}specific_direct taken from <a href="http://www.opensource.apple.com/source/Libc/Libc-825.40.1/pthreads/pthread_machdep.h" target="_blank">http://www.opensource.apple.com/source/Libc/Libc-825.40.1/pthreads/pthread_machdep.h</a> and 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.<br>


<br>
</div>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.<br>


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


<br>
Cheers.<br>
<span class=""><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div></div></div>