search for: get_tcb_address

...t the stack guard into TCB. 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. 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. Details are in the bug: https://llvm.org/bugs/show_bug.cgi?id=26226 Any ideas? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/l...

On Mon, Feb 22, 2016 at 3:32 PM Joerg Sonnenberger via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Mon, Jan 25, 2016 at 07:57:43PM +0000, Tim Shen via llvm-dev wrote: > > 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. > > It would also be inefficient on architectures that can directly access > TLS variables. I.e. on x86, it is effectively a statically allocated TLS > variable with fixe...

...ult than doing so >> for x86? >> > > Shouldn't be at all, mostly just seems that a bunch of it hasn't been set > up yet. > > -eric > > >> >> -Hal >> >> >>> 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. >>> >>> Details are in the bug: https://llvm.org/bugs/show_bug.cgi?id=26226 >>> >>> Any ideas? >>> >>> >> Not a huge fan of a ppc spec...

...rd code the offset > > of > > stack_guard, but I don't see a easy way to handle address spaces in > > ppc. > Why is handling address spaces in ppc any more difficult than doing so for x86? -Hal > > 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. > > > Details are in the bug: https://llvm.org/bugs/show_bug.cgi?id=26226 > > > Any ideas? > > Not a huge fan of a ppc specific intrinsic (which it should be, so >...

...; or SLB entry on powerpc 64bit?) with a non-negative offset value, so that it's actually accessing data in the specified segment. 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: ~/src/glibc % grep -r 'stack_guard;' . ./sysdeps/mach/hurd/i386/tls.h: uintptr_t stack_guard; ./sysdeps/i386/nptl/tls.h: uintptr_t stack_guard; ./sysdeps/spar...