similar to: [PPC] Linker fails on -fstack-protector

I'll come up with a address-space-based proof of concept. On Wed, Feb 10, 2016, 17:05 Eric Christopher <echristo at gmail.com> wrote: > On Wed, Feb 10, 2016 at 5:04 PM Hal Finkel <hfinkel at anl.gov> wrote: > >> >> ------------------------------ >> >> *From: *"Eric Christopher" <echristo at gmail.com> >> *To: *"Tim

----- Original Message ----- > From: "Eric Christopher" <echristo at gmail.com> > To: "Tim Shen" <timshen at google.com>, llvm-dev at lists.llvm.org, "Hal > Finkel" <hfinkel at anl.gov>, "Kit Barton" <kbarton at ca.ibm.com> > Sent: Wednesday, February 10, 2016 6:59:50 PM > Subject: Re: [llvm-dev] [PPC] Linker fails on

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 accessing

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

On Mon, Feb 22, 2016 at 5:00 PM Eric Christopher <echristo at gmail.com> wrote: > 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

Hi all. For a while, gcc has supported a stack protection mechanism (-fstack-protector and friends, available in gcc 4.1.2 and up). Can anyone think of a good reason not to enable it if the compiler supports it? A quick test here shows minimal difference in runtime over a full regress pass (~10sec over 8.5 minutes, and since the machine is not entirely idle that could be experimental error).

Bill, For some reason the llvm-symbolizer tests fail on ppc: http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/182/steps/ninja%20check%201/logs/stdio because it can't be started: /home/buildbots/ppc64le-clang-test/clang-ppc64le/stage1/./bin/llvm-symbolizer: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by

yo, ive been using the fstack protector for a while now and it worked fine until i was gonna compile 4.8p3 then i got these errors, sio.o(.text+0x18b7): undefined reference to `__guard' sio.o(.text+0x1da9): undefined reference to `__guard' sio.o(.text+0x1db9): undefined reference to `__stack_smash_handler' vga_isa.o: In function `isavga_probe': vga_isa.o(.text+0x10): undefined

I tried building dovecot using : CPPFLAGS="-fstack-protector" LDFLAGS="-lssp" ./configure That would result in a proper build, yet the binary would complain once being run: dlopen(/usr/local/lib/dovecot/imap/lib10_quota_plugin.so) failed: /usr/local/lib/dovecot/imap/lib10_quota_plugin.so: undefined symbol: __stack_chk_fail_local Error: imap dump-capability process returned

On 2 Oct 2012, at 03:26, Magee, Josh wrote: > 1) An address of a local variable is taken in such a way as to expose the > address of a stack location. > - Example: the address of a local on the RHS of an assignment, the > address of a local passed into function. This sounds like something that would be triggered for any function containing a block, even if the

David Chisnall wrote: >On 2 Oct 2012, at 03:26, Magee, Josh wrote: > >> 1) An address of a local variable is taken in such a way as to expose the >> address of a stack location. >> - Example: the address of a local on the RHS of an assignment, the >> address of a local passed into function. > > It also sounds like it would be triggered for a

On Mon, Nov 30, 2015 at 7:24 PM Gao, Yunzhong < yunzhong_gao at playstation.sony.com> wrote: > According to > http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html, > "The high-order double-precision value (the one that comes first in > storage) must have the larger magnitude." > > So the order of the two doubles in your fp128 is not affected by the

Hello, Does the -fstack-protector option work on CLANG 3.1 and 3.2? There is thread on FreeBSD forums about the stack protector and ports and I'm wondering if it's possible to use the -fstack-protector option with CLANG. http://forums.freebsd.org/showthread.php?t=36927 -Kimmo

Hi, I'm recently trying to investigate ppc_fp128 related problem. Here is a minimal C++ test case that seems wrongly compiled: long double id(long double a) { return a; } bool f(long double x) { return id(__builtin_fabsl(x)) >= 0; } int main() { if (f(-123.l)) { return 0; } return 1; } The program compiled with command: clang++ -static -target powerpc64le-linux-gnu bad.cc

hi is there any way to build 4.8 release with this fstack protection? or atleast some ports is there any good info on this? the only page i found was that ibm page but it seemed outdated. //martin

Hi, List, In checking the page fault problem when using pv-grub to start domU in opensuse12.3[1], found that the problem is caused by ''-fstack-protector'' flag which is introduced in rpm build: export EXTRA_CFLAGS_XEN_TOOLS="$RPM_OPT_FLAGS" export EXTRA_CFLAGS_QEMU_TRADITIONAL="$RPM_OPT_FLAGS" export EXTRA_CFLAGS_QEMU_XEN="$RPM_OPT_FLAGS" with

It would appear that the fix for https://bugs.llvm.org/show_bug.cgi?id=24155 really only applies to X86. Which I suppose is fine since that's where the bug was reported. However, we've recently upgraded the OS's on some of our PPC64 systems and are hitting the same problems. I certainly wouldn't mind providing a similar fix for PPC, but I don't know what the values in

On PowerPC we have a failing address sanitizer test when linking with LLD. The issue is that the symbol '__libc_stack_end' is resolved to an undefined weak symbol when linking with LLD but not when linking (with the exact same command/input) with other linkers. Tracing the symbol I see it is resolved to a definition in the dynamic linker as expected:

On 10/1/12 9:26 PM, Magee, Josh wrote: > Hello, > > I plan to implement "Stack Smashing Protection - Strong" support in LLVM. > Below is a description of this feature and an overview of the implementation > plan. I have divided up the implementation into stages that can be delivered > incrementally. > > I'm looking for any feedback (suggestions, requests,

Hello, I plan to implement "Stack Smashing Protection - Strong" support in LLVM. Below is a description of this feature and an overview of the implementation plan. I have divided up the implementation into stages that can be delivered incrementally. I'm looking for any feedback (suggestions, requests, etc) before I actually begin the work. Thank you! Josh