search for: stack_guard

I found a bit weird to use address space for this, since the offset of getting stack_guard in TCB is, unfortunately, negative: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/rs6000/linux64.h#L610 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...

...r powerpc64le, glibc doesn't provide this symbol. >>> Instead, they put 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. >>> >> >> >> Why is handling address spaces in ppc any more difficult than doing so >> for x86? >> > > Shouldn't be at all, mostly just seems that a bunch of it hasn't been set >...

...ind the symbol "__stack_chk_guard" because at least for powerpc64le, glibc doesn't provide this symbol. Instead, they put 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...

...powerpc64le, glibc > > doesn't > > provide this symbol. Instead, they put 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. > 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_g...

..., 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 fixed offset. That can be accessed by a single load -- &...