similar to: [LLVMdev] Disabling Fortify in llvm

> On 30 March 2018 at 15:08 "A. Schulze" <sca at andreasschulze.de> wrote: > > > Hello, > > to build + packages dovecot I use the usual Debian tool chain. That includes build with selected GCC options and running lintian. > > I notice since a long time (read: many earlier versions, up to 2.2.35) this lintian warnings: > > I: dovecot-core:

Hello, to build + packages dovecot I use the usual Debian tool chain. That includes build with selected GCC options and running lintian. I notice since a long time (read: many earlier versions, up to 2.2.35) this lintian warnings: I: dovecot-core: hardening-no-fortify-functions usr/lib/dovecot/auth N: N: This package provides an ELF binary that lacks the use of fortified libc N:

Just to keep others in loop. This issue has been fixed by following additions in Makefile: CPP.Flags += -U_FORTIFY_SOURCE CPP.Flags += -D_FORTIFY_SOURCE=0 Thanks, Ahmad From: ahmad.hassan at sap.com Sent: 07 January 2013 19:52 To: llvmdev at cs.uiuc.edu Subject: _FORTIFY_SOURCE warnings Hi All, I have modified the Makefile inside llvm/tools/clang and added the following flag: CPP.Flags +=

Hi Ahmad, If the Makefile contains only this command, then it is not worth spending time on GoldPlugin. If you are building a large project, then it will be simpler to use GoldPlugin. The steps you are using seem right. You can possibly combine the last two steps (3&4) using only 1 clang command. clang -g -O2 -o .libs/mergedexe .libs/mergedbc.bc -pthread -Wl,--export-dynamic

"Hassan, Ahmad" <ahmad.hassan at sap.com> writes: > I would like to ask if LLVM provides a utility function like > 'isMallocCall' to check if the 'call' instruction is calling some > 'foo' user defined function? > > If there is no such utility function then I am thinking to do this in > the following way: > > bool testFoo(CallInst

Hi Ahmad, Yes, merging works good. However, my problem is like this - I have a C library which consists of 1000's of functions spread through various files. The functions do not have dependency amoung each other. I want to link only relavant files( files which have functions called from my application). Since ar has a global symbol table, I believe it should be faster to look for a symol in

Hi, I would like to ask if LLVM provides a utility function like 'isMallocCall' to check if the 'call' instruction is calling some 'foo' user defined function? If there is no such utility function then I am thinking to do this in the following way: bool testFoo(CallInst *CI) { Function *Callee = CI->getCalledFunction(); if (Callee->getName() == "foo")

Hi All, I have modified the Makefile inside llvm/tools/clang and added the following flag: CPP.Flags += -D_FORTIFY_SOURCE=0 But when I build clang using 'make' then I get lot of warnings like: <command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined [enabled by default] <built-in>:0:0: note: this is the location of the previous definition Is this expected

Hi folks (CCing llvm-dev, but that's probably more of a cfe-dev topic), As a follow-up to that old thread about -D_FORTIFY_SOURCE=n http://lists.llvm.org/pipermail/cfe-dev/2015-November/045845.html And, more recently, to this fedora thread where clang/llvm -D_FORTIFY_SOURCE support is claimed to be only partial: https://pagure.io/fesco/issue/2020 I dig into the glibc headers in

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> [ Upstream commit a7ed3465daa240bdf01a5420f64336fee879c09d ] When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to

From: "GONG, Ruiqi" <gongruiqi1 at huawei.com> When compiling with gcc 13 and CONFIG_FORTIFY_SOURCE=y, the following warning appears: In function ?fortify_memcpy_chk?, inlined from ?size_entry_mwt? at net/bridge/netfilter/ebtables.c:2118:2: ./include/linux/fortify-string.h:592:25: error: call to ?__read_overflow2_field? declared with attribute warning: detected read beyond

Hi Duncan, > 4.gcc -g -O2 -o .libs/mergedexe .libs/mergedbc.s -pthread > -Wl,--export-dynamic .libs/lib1.a -lssl -lcrypto -ldl -pthread .libs/lib2.so >if you pass -O4 rather than -O2 to clang I think it will in essence do this all >for you already. It might even do the link time optimization for you at -O2 >even, I'm not sure. No, if I use clang for producing

Hi All, I am migrating a build system of an existing project from 'Object files' based executable generation to 'LLVM Bitcode' files based exe generation and applying OPT pass to LLVM Bitcode. I found out the following 4 step procedure. Please let me know if this is the right procedure or is there any other easy way of doing it. I need to modify 'Makefile' accordingly. I

> Are you sure you've diagnosed the issue correctly? __builtin___memcpy_chk works correctly, as far as I know. 100% sure. Let's have a look at the output of #include <string.h> static char dest[10]; char* square(int n) { memcpy(dest, "hello", n); return dest; } compiled with -D_FORTIFY_SOURCE=1 -O1 : https://godbolt.org/z/UvABWp Clang issues a call to

Hi Ankur, Why do you need archive in this case? The other way of doing this is to merge all bitcode files into single file: $ clang -c -emit-llvm abc.c -o abc.bc $ clang -c -emit-llvm bcd.c -o bcd.bc llvm-link bcd.bc abc.bc -o merged.bc Cheers, Ahmad From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of ankur deshwal Sent: 21 February 2013 17:54 To: