<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" ><span style="font-size:0.857em;" >Hi Tim,</span></div>
<div dir="ltr" ><span style="font-size:0.857em;" >I'm a little confused about what you're trying to accomplish here.</span></div>
<div dir="ltr" ><span style="font-size:0.857em;" >Are you trying to find a way to access the stack_guard in the TCB provided by glibc? </span></div>
<div dir="ltr" ><span style="font-size:0.857em;" >If not, can we not just come up with our own definition of __stack_chk_guard and discuss the best way to implement that (perhaps not by putting it in the TCB)?</span></div>
<div dir="ltr" > </div>
<div dir="ltr" ><span style="font-size:0.857em;" >I'm not familiar with the GCC implementation, but I can talk to the GCC folks tomorrow to get some more details. I know that XL implemented this differently, but some specific details are a bit fuzzy. I'll refresh my memory on that tomorrow as well.</span></div>
<div dir="ltr" > </div>
<div dir="ltr" ><span style="font-size:0.857em;" >Thanks,</span></div>
<div dir="ltr" > </div>
<div dir="ltr" ><span style="font-size:0.857em;" >Kit Barton, Ph.D.<br>LLVM Development on POWER<br>IBM Toronto Lab, D2/929/8200/MKM<br>8200 Warden Ave, Markham, L6G 1C7<br>(905) 413-3452<br>kbarton@ca.ibm.com</span>
<div> </div>
<div> </div>
<blockquote data-history-content-modified="1" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: Tim Shen <timshen@google.com><br>To: Eric Christopher <echristo@gmail.com>, Hal Finkel <hfinkel@anl.gov>, Joerg Sonnenberger <joerg@britannica.bec.de><br>Cc: llvm-dev@lists.llvm.org, Kit Barton/Toronto/IBM@IBMCA, "kyle+llvm@iteratee.net" <kyle+llvm@iteratee.net><br>Subject: Re: [llvm-dev] [PPC] Linker fails on -fstack-protector<br>Date: Mon, Feb 22, 2016 11:47 PM<br> 
<div dir="ltr" ><div dir="ltr" ><div><div dir="ltr" >On Mon, Feb 22, 2016 at 5:00 PM Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank" >echristo@gmail.com</a>> wrote:</div>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" ><div dir="ltr" ><div><div>Yeah, for most of the architectures listed there it's not particularly useful as they support direct access to TLS variables (as Joerg says later). That grep isn't representative of how the data is actually accessed. If the current address space way of specifying isn't doable on PPC then that's fine (or feels icky).</div></div></div></blockquote>
<div> </div>
<div>It is certainly doable, but I feel icky:</div>
<div>1) It needs to support negative offset, which is weird when we are talking about address spaces;</div>
<div>2) Handling TLS is totally different from handling real ppc segments (which I assume address space is designed for);</div>
<div>3) TLS has a different semantic from address space (<a href="http://llvm.org/docs/CodeGenerator.html#x86-address-spaces-supported" target="_blank" >http://llvm.org/docs/CodeGenerator.html#x86-address-spaces-supported</a>).</div>
<div> </div>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" ><div dir="ltr" ><div><div>That said, the basic idea of keeping around the way to access the TLS variable is pretty easy, we do some amount of this in TargetLowering::getStackCookieLocation, but we might just need to come up with a new interface there that returns the address of the stack local load rather than an offset from an address space.</div></div></div></blockquote>
<div> </div>I also found a similar case - getSafeStackPointerLocation(). On X86 it's implemented in terms of address space (similar to getStackCooikeLocation), but on AArch64 it's implemented in terms of a target specific AArch64ISD::THREAD_POINTER and Intrinsic::aarch64_thread_pointer.</div>
<div><div> </div>
<div>To make the fix least surprising, I can either do:</div>
<div>1) Create PPCISD::THREAD_POINTER and Intrinsic::ppc_thread_pointer and do similar things aarch64 does; or</div>
<div>2) Don't create PPCISD::THREAD_POINTER, but directly calls llvm.read_register intrinsic in ppc's getStackCookieLocation(). This is the way that requires least change; or</div>
<div>3) Create a generic ISD::GET_GLOBAL_TLS_ADDRESS and intrinsic llvm.get_global_tls_address(), and lower them to target specific ISD. No target specific intrinsic is needed. I was wrong about ISD::GlobalTlsAddress, since it requires a GlobalValue object.</div>
<div> </div>
<div>I prefer 3), since it's less hacky than 2) and less repetitive than 1).</div></div></div></div></blockquote></div></div><BR>