search for: fpie

Hello everyone, Clang seems to only define __PIE__ when both –fPIC and –fPIE is used in the command line whereas gcc defines both __PIC__ and __PIE__. Is this intended or a bug in clang? Thanks. Command line: clang -fPIC -fPIE -dM -E - < /dev/null | grep __PI -- Tareq

...ekeeping index 1f5e115..d49416e 100644 --- a/gpxe/src/Makefile.housekeeping +++ b/gpxe/src/Makefile.housekeeping @@ -134,6 +134,16 @@ SP_FLAGS := $(shell $(SP_TEST) && $(ECHO) '-fno-stack-protector') CFLAGS += $(SP_FLAGS) endif +# Some widespread patched versions of gcc include -fPIE -Wl,-pie by +# default. gpxe does not support pie code in get_cpuinfo. +# +ifeq ($(CCTYPE),gcc) +PIE_TEST = $(CC) -fno-PIE -nopie -x c -c /dev/null \ + -o /dev/null >/dev/null 2>&1 +PIE_FLAGS := $(shell $(PIE_TEST) && $(ECHO) '-fno-PIE -nopie') +CFLAGS += $(PIE_FLAGS) +en...

If I create an llvm IR file (.ll) using clang like this: clang -v -emit-llvm -fPIC -O0 -S global_dat.c -o global_dat_x86_pic.ll And then take a look at the resulting .ll file, I see near the bottom: !0 = !{i32 1, !"PIC Level", i32 2} Now if I do the same, but specify -fPIE: clang -v -emit-llvm -fPIE -O0 -S global_dat.c -o global_dat_x86_pie.ll And then look at the resulting global_dat_x86_pie.ll file, I see it is identical to the one where I specified -fPIC (global_dat_x86_pic.ll). There's no indication of the PIE level in the .ll file. However, I can see (b...

...ekeeping index 1f5e115..d351a52 100644 --- a/gpxe/src/Makefile.housekeeping +++ b/gpxe/src/Makefile.housekeeping @@ -134,6 +134,17 @@ SP_FLAGS := $(shell $(SP_TEST) && $(ECHO) '-fno-stack-protector') CFLAGS += $(SP_FLAGS) endif +# Some widespread patched versions of gcc include -fPIE -Wl,-pie by +# default. Note that gcc will exit *successfully* if it fails to +# recognise an option that starts with "no", so we have to test for +# output on stderr instead of checking the exit status. +# +ifeq ($(CCTYPE),gcc) +PIE_TEST = [ -z "`$(CC) -fno-PIE -nopie -x c -c /dev/...

...l, I compiled the following code on my linux PC using clang with PIE option- struct struct4 {char a; char b; char c; char d; }; struct struct4 foo4 = {'a','2','c','4'}; struct struct4 fun4() { return foo4; } int main() { fun4(); return 0; } > clang -g -fPIE structs.c In GDB session when i call p/c fun4() i get something like below- (gdb) p/c fun4() Cannot access memory at address 0x34633261 Disassemble of the code is as follows - (gdb) disassemble Dump of assembler code for function fun4: 0x080483e0 <+0>: call 0x80483e5 <fun4+5>...

...IGNED MESSAGE----- Hash: SHA1 Just attempted to build 3.0.23pre1 on HP-UX 11.11 today, preparing for a planned move to a later version of 3.0.x (we're currently down at 3.0.11). Configure ran fine, but make eventually failed here: Compiling lib/sysacls.c cc: warning 422: Unknown option "fPIE" ignored. cc: "lib/sysacls.c", line 1277: warning 611: Type conversion loses "const" qualifier. cc: "lib/sysacls.c", line 1321: error 1588: "oldtext" undefined. cc: "lib/sysacls.c", line 1321: warning 563: Argument #1 is not the correct type. m...

On Fri, Nov 6, 2015 at 11:10 AM, Tim Northover <t.p.northover at gmail.com> wrote: > On 6 November 2015 at 11:00, Phil Tomson <phil.a.tomson at gmail.com> wrote: > > With 3.6 I get an unused argument warning with -enable-pie: > > > > $ clang -v -emit-llvm -enable-pie -O0 -S global_dat.c -o > > global_dat_x86_pie.ll > > Yes, it's an llc option not a

On Fri, Nov 6, 2015 at 10:46 AM, Tim Northover <t.p.northover at gmail.com> wrote: > On 6 November 2015 at 10:32, Phil Tomson via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > So if I were to pass this .ll file (global_dat_x86_pie.ll) to llc how > would > > llc know that the PIE Level is 2? Is this an oversight, bug, or expetcted > > behaviour with a

On Sat, Sep 12, 2015 at 7:48 PM, Greg Stark <stark at mit.edu> wrote: > I get that even if I put -fPIE in CFLAGS. Er, yeah. Even a trivial test case doesn't work: $ cat foo.c int main(int argc, char *argv[], char *envp[]) { return 1; } $ clang -o foo -fsanitize=memory -fPIE -pie foo.c $ sysctl kernel.randomize_va_space kernel.randomize_va_space = 2 $ ./foo FATAL: Code 0x55873d194390 is ou...

...e >> because it calls __tls_get_address in loops. >> While with optimization disabled >> It produce single call to __tls_get_address outside of loop. >> is this a missed optimization by llvm? >> > > It's interesting to me that there's a big difference in -fpie and -fpic. > > https://godbolt.org/z/klX3q3 > > In particular, with -fpie, no call to __tls_get_addr is needed, so the > underlying considerations for optimization change. This feels like the > optimizer isn't taking in to account the overhead of -fpic, when > determining...

...s to use the small code model but can run at >4GB high address. Small, but PIC. > For example if you read a global like this the compiler will generate this code. > int constant = 0; > > int get_constant(void) > { > return constant; > } Compiling for ELF with -FPIE -Os I get get_constant: # @get_constant # BB#0: # %entry movl constant(%rip), %eax retq Which should also be able to run at any address. Cheers, Rafael

...dn't change anything). Then any program I compile with -fsanitize=memory behaves just like it did before the patch: $ uname -a Linux pixel 4.2.0-trunk-amd64 #1 SMP Debian 4.2-1~exp1 (2015-08-31) x86_64 GNU/Linux $ cat foo.c int main(int argc, char *argv[], char *env[]) { return 0; } $ clang -fPIE -pie -fsanitize=memory foo.c $ ./a.out FATAL: Code 0x562988448390 is out of application range. Non-PIE build? FATAL: MemorySanitizer can not mmap the shadow memory. FATAL: Make sure to compile with -fPIE and to link with -pie. FATAL: Disabling ASLR is known to cause this error. FATAL: If running u...

I downloaded SAMBA VERSION: 3.0.20b to my sun sol 9 server and below is the error I got after running ./configure. root@cpkfs1# ./configure SAMBA VERSION: 3.0.20b checking for -fPIE... checking for gcc... no checking for cc... cc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. This is the details from the config.log file. root@cpkfs1# more config.log This file contains any me...

> Portable OpenSSH is also available via [...] Github: https://github.com/openssh/openssh-portable > > Running the regression tests supplied with Portable OpenSSH does not require installation and is a simply: > > $ ./configure && make tests I was going to try this on Kali Linux (latest version), but ran into trouble right away. No "configure" script exists

On Thu, Jun 07, 2018 at 06:14:42PM -0700, PGNet Dev wrote: > On 6/7/18 6:08 PM, Darren Tucker wrote: > > Well the intent is you should be able to set CC and LD to whatever you > > want as long as they work. In this case, the OSSH_CHECK_LDFLAG_LINK > > test invokes autoconf's AC_LINK_IFELSE with uses CC not LD. I'm not > > sure what to do about it yet though. I

Hi Devs, Consider testcase here https://godbolt.org/z/qHZzqw When optimization is O1 or above it produces unoptimized code because it calls __tls_get_address in loops. While with optimization disabled It produce single call to __tls_get_address outside of loop. is this a missed optimization by llvm? ./Kamlesh

...r flags: -g -O2 -pipe -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -mfunction-return=thunk -mindirect-branch=thunk -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-strong -fPIE Preprocessor flags: -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE Linker flags: -Wl,-z,retpolineplt -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -fstack-protector-strong -pie Libraries: -lutil -lz -lcrypt -lresolv reports no errors. build, make V=1 ... a - platf...

OK, I get it. Adding "-pie" link option can force 64bits relocation address (e.g. EM_X86_64), instead of the 32bits one (e.g. R_X86_64_32S). I only used -fpic and -fpie in clang LTO compile option, and forgot add the "-pie" link option in ld. So my clang + ld LTO executable was still not position independent. Thank you all! Steven Shi Intel\SSG\STO\UEFI Firmware Tel: +86 021-61166522 iNet: 821-6522 > -----Original Message----- > From: Rafael E...

Hello, Could I please ask you for help? I opened a case in GCC Bugzilla and got reply that -fpie have to be used to get it compiled. Now it fails for me with: x86_64-pc-linux-gnu-gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o -L. -Lopenbsd-compat/ -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto...

On Sat, Sep 5, 2015 at 11:50 AM, Greg Stark <stark at mit.edu> wrote: > On Sat, Sep 5, 2015 at 6:38 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > This is more like a limitation of asan, not libFuzzer. > > By design, asan does not recover from the first crash. > > This feature has been criticized quite a lot, but I am still convinced > this >