search for: __memcpy_chk

> 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 Clan...

...en(i8* %0) nounwind readonly %3 = call i64 @strlen(i8* %1) nounwind readonly %4 = add i64 %2, 1 %5 = add i64 %4, %3 %6 = call noalias i8* @malloc(i64 %5) nounwind %7 = call i64 @strlen(i8* %0) nounwind readonly %8 = call i64 @llvm.objectsize.i64(i8* %6, i1 false) %9 = call i8* @__memcpy_chk(i8* %6, i8* %0, i64 %7, i64 %8) nounwind %10 = call i64 @strlen(i8* %1) nounwind readonly %11 = add i64 %10, 1 %12 = call i64 @strlen(i8* %0) nounwind readonly %13 = getelementptr i8* %6, i64 %12 %14 = call i64 @llvm.objectsize.i64(i8* %13, i1 false) %15 = call i8* @__memcpy_chk(i...

Hi Pablo, I can reproduce this with the supplied IR. It is related to the use of __memcpy_chk. As far as I can see it is a bug in lli or the LLVM code generators. Can you please open a bugreport, attaching the LLVM IR. Ciao, Duncan. On 23/01/12 17:00, Pablo Barrio wrote: > Hi Duncan, >>> #include<stdio.h> >>> #include<string.h> >>> >>>...

Hi all, Working with llvm 2.8 installed on Mac OS, when using the llvm-gcc frontend and the C backend I see it converting regular (non-checking) memcpy and memset calls to __memset_chk and __memcpy_chk already at the IR stage. Then in the CBE output these are retained as gcc builtin functions. In a similar manner, llvm.objectsize.* calls are replaced with __builtin_object_size calls, another gcc builtin function. This way the resulting C code is usable as-is only on gcc-compatible compilers. Is...

...ult. You can turn it off by passing -fno-stack-protector to dragonegg. However please still open a bugreport since stack protection is supposed to work. Ciao, Duncan. On 24/01/12 09:52, Duncan Sands wrote: > Hi Pablo, I can reproduce this with the supplied IR. It is related to the use of > __memcpy_chk. As far as I can see it is a bug in lli or the LLVM code > generators. Can you please open a bugreport, attaching the LLVM IR. > > Ciao, Duncan. > > On 23/01/12 17:00, Pablo Barrio wrote: >> Hi Duncan, >>>> #include<stdio.h> >>>> #include<string...

> Working with llvm 2.8 installed on Mac OS, when using the llvm-gcc frontend > and the C backend I see it converting regular (non-checking) memcpy and > memset calls to __memset_chk and __memcpy_chk already at the IR stage. Most probably these are changed due to defines in the system headers, so, compiler cannot do anything about this. You can hack on your system headers though. > In a similar manner, llvm.objectsize.* calls are replaced with > __builtin_object_size calls, another gcc b...

Hi Pablo, > I came across something that seems to be a bug in the dragonegg option that > emits LLVM IR. ¿Can anybody reproduce the error, or see what's wrong? I can't reproduce this on x86-64 linux with latest LLVM+dragonegg+gcc-4.6. ¿Should I > post it somewhere else in case it's really a bug? Thanks ahead! > > With this simple program: > * > #include

Hi all, I came across something that seems to be a bug in the dragonegg option that emits LLVM IR. ¿Can anybody reproduce the error, or see what's wrong? ¿Should I post it somewhere else in case it's really a bug? Thanks ahead! With this simple program: * #include <stdio.h> #include <string.h> int main(int argc, char** argv){ char a[8] = "aaaaaaa";

...ert that I wrote a small test suite: https://github.com/serge-sans-paille/fortify-test-suite And indeed, clang doesn't pass it, mostly because it turns call to __builtin__(.*)_chk into calls to __builtin__\1. We need to support the runtime behavior of the following builtins: - __builtin___memcpy_chk - __builtin___memmove_chk - __builtin___mempcpy_chk - __builtin___memset_chk - __builtin___snprintf_chk - __builtin___sprintf_chk - __builtin___stpcpy_chk - __builtin___strcat_chk - __builtin___strcpy_chk - __builtin___strncat_chk - __builtin___strncpy_chk - __builtin___vsnprintf_chk - __builtin___...

...amework is proposed. Proposal ======== The following three sections specify a proposal for how the work will be broken down. In a way they specify milestones. Extend test coverage -------------------- Between the two existing methods the following library calls are folded: 1. `InstCombiners`: __memcpy_chk, __mempcpy_chk, __memset_chk, __strcpy_chk, __stpcpy_chk, __strncpy_chk, __stpncpy_chk, __strcat_chk, __strncat_chk. 2. `SimplifyLibCalls`: strcat, strncat, strchar, strrchr, strcmp, strncmp, strcpy, strncpy, strlen, strpbrk, strtol, strtod, strtof, strtoul, strtoll, strtold, strtoull, s...

Hello all, Pardon me if this has already been covered elsewhere, however I have not been able to find such documentation. Is there a consolidated set of documentation that clearly explains what's necessary to port LLVM to other OSes & how to add support for building executables (& libraries) for those OSes? I'm searching through the source in an attempt to understand what needs to

...libsamba-util.dylib 0x000000010155a653 sig_fault + 19 #5 5 libsystem_platform.dylib 0x00007fff913a752a _sigtramp + 26 #6 6 ??? 0x0000000083442f30 0x0 + 2202283824 #7 7 libsystem_c.dylib 0x00007fff82d45f13 __memcpy_chk + 22 #8 8 libgssapi-samba4.dylib 0x0000000101ab5d06 _gss_copy_oid + 150 #9 9 libgssapi-samba4.dylib 0x0000000101ab89e3 gss_import_name + 259 #10 10 libads-samba4.dylib 0x0000000102b58677 ads_generate_service_principal + 359 #11 11 libads-s...

...REDIR: 0x52f34f0 (libc.so.6:strncmp) redirected to 0x4a24716 (_vgnU_ifunc_wrapper) --3135-- REDIR: 0x52f5850 (libc.so.6:bcmp) redirected to 0x4a24716 (_vgnU_ifunc_wrapper) --3135-- REDIR: 0x52f1890 (libc.so.6:strcmp) redirected to 0x4a24716 (_vgnU_ifunc_wrapper) --3135-- REDIR: 0x5377850 (libc.so.6:__memcpy_chk) redirected to 0x4a24716 (_vgnU_ifunc_wrapper) --3135-- REDIR: 0x52f4e00 (libc.so.6:__GI_strrchr) redirected to 0x4c2c520 (__GI_strrchr) --3135-- REDIR: 0x52ec890 (libc.so.6:malloc) redirected to 0x4c29b76 (malloc) --3135-- REDIR: 0x52ecc90 (libc.so.6:free) redirected to 0x4c2ac90 (free) --3135-- R...

WINS nsswitch module -------------------- The WINS nsswitch module has been rewritten to address memory issues and to simplify the code. The module now uses libwbclient to do WINS queries. This means that winbind needs to be running in order to resolve WINS names using the nss_wins module. This does not affect smbd. my problem: old versions >> ping google.com >> PING google.com