<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 22, 2016 at 3:23 PM Tim Shen <<a href="mailto:timshen@google.com">timshen@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I found a bit weird to use address space for this, since the offset of getting stack_guard in TCB is, unfortunately, negative:<div><a href="https://github.com/gcc-mirror/gcc/blob/master/gcc/config/rs6000/linux64.h#L610" target="_blank">https://github.com/gcc-mirror/gcc/blob/master/gcc/config/rs6000/linux64.h#L610</a></div><div><br></div><div>In my understanding an address space is referring to a segment register (-on powerpc 32bit; or SLB entry on powerpc 64bit?) with a non-negative offset value, so that it's actually accessing data in the specified segment.</div><div><br></div><div>In our case, I feel accessing r13 (TCB pointer) is more different than I thought. I'm considering turning to add a target *independent* IR intrinsic "llvm.get_tcb_address()". It's target independent because glibc does this for several platforms, and we probably want to solve it once for all:</div><div><div>~/src/glibc % grep -r 'stack_guard;' .</div><div>./sysdeps/mach/hurd/i386/tls.h: uintptr_t stack_guard;</div><div>./sysdeps/i386/nptl/tls.h: uintptr_t stack_guard;</div><div>./sysdeps/sparc/nptl/tls.h: uintptr_t stack_guard;</div><div>./sysdeps/s390/nptl/tls.h: uintptr_t stack_guard;</div><div>./sysdeps/powerpc/nptl/tls.h: uintptr_t stack_guard;</div><div>./sysdeps/x86_64/nptl/tls.h: uintptr_t stack_guard;</div><div>./sysdeps/tile/nptl/tls.h: uintptr_t stack_guard;</div></div></div></blockquote><div><br></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). 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><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Opinions?</div></div><div dir="ltr"><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 19, 2016 at 6:39 PM Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sounds good.<div><br></div><div>Thanks!</div></div><div dir="ltr"><div><br></div><div>-eric</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 19, 2016 at 6:38 PM Tim Shen <<a href="mailto:timshen@google.com" target="_blank">timshen@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I'll come up with a address-space-based proof of concept.</p>
<br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 10, 2016, 17:05 Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Feb 10, 2016 at 5:04 PM Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><br><hr><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"Eric Christopher" <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>><br><b>To: </b>"Tim Shen" <<a href="mailto:timshen@google.com" target="_blank">timshen@google.com</a>>, <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>, "Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>, "Kit Barton" <<a href="mailto:kbarton@ca.ibm.com" target="_blank">kbarton@ca.ibm.com</a>><br><b>Sent: </b>Wednesday, February 10, 2016 6:59:50 PM<br><b>Subject: </b>Re: [llvm-dev] [PPC] Linker fails on -fstack-protector</blockquote></div></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><br><br><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 25, 2016 at 11:58 AM Tim Shen via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>When -fstack-protector is turned on, linker fails to find the symbol "<span style="color:rgb(0,0,0);line-height:normal;white-space:pre-wrap">__stack_chk_guard" because at least for powerpc64le, glibc doesn't provide this symbol. Instead, they put the stack guard into TCB.</span></div><div><span style="color:rgb(0,0,0);line-height:normal;white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);line-height:normal;white-space:pre-wrap">x86 fixed this issue by injecting a special address space (which is later translated to TCB register access) and hard code the offset of stack_guard, but I don't see a easy way to handle address spaces in ppc.</span></div></div></blockquote><br></div></div></blockquote></div></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"></blockquote><br>Why is handling address spaces in ppc any more difficult than doing so for x86?<br></div></div></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Shouldn't be at all, mostly just seems that a bunch of it hasn't been set up yet.</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><div>-eric</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><br> -Hal</div></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000"><br><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><span style="color:rgb(0,0,0);line-height:normal;white-space:pre-wrap"></span></div><div><span style="color:rgb(0,0,0);line-height:normal;white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);line-height:normal;white-space:pre-wrap">A cleaner solution could be adding an IR intrinsic llvm.get_tcb_address() and hard code the offset of stack_guard member, since they aren't supposed to change.</span></div><div><br></div>Details are in the bug: <a href="https://llvm.org/bugs/show_bug.cgi?id=26226" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=26226</a><br><div><br></div><div>Any ideas?</div><div><br></div></div></blockquote><div><br></div><div>Not a huge fan of a ppc specific intrinsic (which it should be, so llvm.ppc... if we go that route) to do this. I actually rather liked the cleanliness of the address space solution for x86. How much work would it be to do that? Alternately: Hal, Kit, what do you two think as far as the ppc backend?</div><div><br></div><div>The other solution you mentioned - combining the slot load into the existing intrinsic might work, we'd just need to figure out how to autoupgrade everything into it which might be a bit more difficult than fixing the backends and dealing. Have you looked into how the autoupgrade would work?</div><div><br></div><div>Thanks!</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Thanks!</div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>
</blockquote><br><br><br></div></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:#000000">-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></div></blockquote></div></div></blockquote></div>
</blockquote></div>
</blockquote></div></div></div></blockquote></div></div>