search for: __printf_chk

...nwind 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(i8* %13, i8* %1, i64 %11, i64 %14) nounwind %16 = call i32 (i32, i8*, ...)* @__printf_chk(i32 1, i8* getelementptr inbounds ([24 x i8]* @.cst2, i64 0, i64 0), [15 x i8]* %memtmp, [15 x i8]* %memtmp1, i8* %6) nounwind ret i32 undef } declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture, i8* nocapture, i64, i32, i1) nounwind declare i64 @strlen(i8* nocapture) nounwind readonly d...

...4 %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(i8* %13, i8* %1, i64 %11, i64 %14) nounwind > %16 = call i32 (i32, i8*, ...)* @__printf_chk(i32 1, i8* > getelementptr inbounds ([24 x i8]* @.cst2, i64 0, i64 0), [15 x i8]* > %memtmp, [15 x i8]* %memtmp1, i8* %6) nounwind > ret i32 undef > } > > declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture, i8* nocapture, > i64, i32, i1) nounwind > > declare i64 @s...

...4 %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(i8* %13, i8* %1, i64 %11, i64 %14) nounwind >> %16 = call i32 (i32, i8*, ...)* @__printf_chk(i32 1, i8* >> getelementptr inbounds ([24 x i8]* @.cst2, i64 0, i64 0), [15 x i8]* >> %memtmp, [15 x i8]* %memtmp1, i8* %6) nounwind >> ret i32 undef >> } >> >> declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture, i8* nocapture, >> i64, i32, i1) nounwind...

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

...+{ + glibc_3 + Memcheck:Leak + ... + fun:bindtextdomain +} + +# Both gmtime_r and locatime_r leak some sort of timezone- related +# struct inside glibc. These are used by the log filter and the +# floppy plugin. +{ + glibc_4 + Memcheck:Leak + fun:malloc + ... + fun:tzset_internal +} + +# __printf_chk leaks. +{ + glibc_5 + Memcheck:Leak + fun:malloc + ... + fun:__printf_chk +} + +# iconv is very leaky, even if we close the handle. +{ + glibc_6 + Memcheck:Leak + fun:malloc + ... + fun:__gconv_open +} + +{ + glibc_7 + Memcheck:Leak + fun:calloc + ... + fun:__gconv_open +} + +# getad...

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";

...555914734480, 0x55591474bc20, 0x7ffff4a0f480, 1) = 0 20582 sid_type_lookup(1, 1104, 0, 0x55591475e6c0) = 0x7f3e4eb07305 20582 dom_sid_str_buf(0x555914761c00, 0x7ffff4a0f4a0, 0x7f3e4eb109a0, 1) = 0x7ffff4a0f4a0 20582 __printf_chk(1, 0x5559133fcb55, 0x55591474ac24, 0x7ffff4a0f4a0) = 62 20582 dcerpc_lsa_Close(0x55591474efc0, 0x55591474bc20, 0x7ffff4a0f480, 0x7ffff4a0f46c) = 0 20582 _talloc_free(0x55591474bc20, 0x5559134498a8, 0x5559146fd010, 0) = 0 20582 free(0x5559...

...t;hello.c" .ident "GCC: (Ubuntu/Linaro 4.5.1-7ubuntu2) 4.5.1 LLVM: " .text .globl main .align 16, 0x90 .type main, at function main: pushl %ebp movl %esp, %ebp subl $8, %esp movl $.L.str, 4(%esp) movl $1, (%esp) call __printf_chk xorl %eax, %eax addl $8, %esp popl %ebp ret .Ltmp0: .size main, .Ltmp0-main .type .L.str, at object .section .rodata.str1.1,"aMS", at progbits,1 .L.str: .asciz "hello world\n" .size .L.str, 13 .section .note.GNU-st...

I worked out why valgrind wasn't being applied to nbdkit when run by many of the tests (patches 1-2). Unfortunately I'm not able to make it actually fail tests when valgrind fails. Although the situation is marginally improved in that you can now manually examine the *.log files and find valgrind failures that way. Also adds valgrinding of the Python plugin (patch 3). Along the way I

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

Typical example: Here is some search & export for libsmbclient: adiant at ubuntu:/usr/lib/x86_64-linux-gnu$ nm -D libsmbclient.so.0 |grep cli_rpc_pipe_open_noauth_transport <nothing> adiant at ubuntu:/usr/lib/x86_64-linux-gnu$ nm -D libsmbclient.so.0 |grep cli_rpc_pipe_open U cli_rpc_pipe_open_noauth adiant at ubuntu:/usr/lib/x86_64-linux-gnu$ nm -D libsmbclient.so.0