search for: dynamorio

...wo weeks? And > if it does not already exists, could it mean it is a nonsense, then why? > > Finally about your proposition using valgrind, I think I will stick to > windows tools because this is what I know better. But it was ironic, wasn't > it? You might want to have a look at DynamoRIO: http://code.google.com/p/dynamorio/ It is also avialable for Windows. Martin > > Alexandre. > > 2009/9/29 Timo Juhani Lindfors <timo.lindfors at iki.fi> >> >> Alexandre Gouraud <alexandre.gouraud at enst-bretagne.fr> writes: >> > like to write the sa...

Hi Timo, Thanks for commenting. I feel like I have to justify why I don't want to use QEMU, which is fine since my choice is not frozen actually. QEMU is much more than what I need for dynamically instrumenting software. My goal is automated testing to find bugs, which can quickly be intensive in term of computational load. Thus I am trying to get the smallest (and fastest) tool. Even using

...urb. :-) > > Share and enjoy! > -bw > Name: ThreadSanitizer, a data race detector. Description: ThreadSanitizer is a data race detector for (mostly) C and C++ code, available for Linux, Mac OS and Windows. On different systems we use binary instrumentation frameworks (Valgrind, Pin and DynamoRio) as frontends that generate the program events for the race detection algorithm. On Linux there's an option of using LLVM-based compile-time instrumentation.

...ster allocation? > Is there a way to tell such temps at compile time before RA? No, I think you need to perform register allocation in order to know about writes to the stack. Are you doing a static analysis on the instructions or are you trying to instrument all memory stores? If so, Pin and DynamoRIO seem like better choices, unless you want to do a static instrumentation, in which case I don't know what the right tool would be. Reid

Hello, I'd like to listen your opinions regarding my research with LLVM. My work is a dynamic analysis of data dependences [1]. Briefly speaking, I'm instrumenting memory loads/stores and loop entries/exits/back edges, and then calculating data dependences in runtime, especially focusing on loop-carried dependences. So far, I have been working with a binary-level instrumentation tool

Hi mobi, Sorry, I am new to clang AST and can not get the point you mentioned. :-( What I try to do is develop a tool that can analyze data dependence at runtime. Therefore, I need to analyze trace containing memory accessing information (eg. arrays within loops). To do that, I first instrument a recording function to get addresses of load/store instructions. However, there are

LLVMers, I need to intercept all LLVM IR instructions that will write into memory and start to do analysis on these instructions. In addition to StoreInst, what are all other IRs that will write into memory? E.g. char * ptr = malloc(...); ///... //with use(s) of ptr later The LLVM IR for the above code would be: %0 = tail call noalias i8* @malloc(i32 137) nounwind ///... //

...emory.pdf for those numbers). But this brings the major issue as well: msan needs to see all program events, including system calls and reads/writes in system libraries, so we either need to compile *everything* with msan or use a binary translation component to instrument pre-built libraries (with DynamoRIO? PIN?). Question: is there any usable project in LLVM land which performs binary instrumentation (x86->LLVM->x86), either statically or dynamically? Another difference from Memcheck is that we propose to use 8 shadow bits per byte of application memory and use a direct shadow mapping (for 6...

You shouldn't need to use bitcode and opt -internalize to hide the symbols. You can do it with objcopy --localize-hidden like we did for DynamoRIO, but I assume you prefer this route because it ports nicely to Mac. :) On Tue, May 7, 2013 at 5:24 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > This might be a bit late, but I've got another argument for bundling > zlib source with LLVM. > > Sanitizer tools n...

...numbers). > But this brings the major issue as well: msan needs to see all program > events, including system calls and reads/writes in system libraries, > so we either need to compile *everything* with msan or use a binary > translation component to instrument pre-built libraries (with DynamoRIO? > PIN?). > > Question: is there any usable project in LLVM land which performs binary > instrumentation (x86->LLVM->x86), either statically or dynamically? > > Another difference from Memcheck is that we propose to use 8 shadow bits > per byte of application memory and u...

On Wed, Apr 20, 2016 at 1:42 PM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 20 April 2016 at 13:18, Yury Gribov <y.gribov at samsung.com> wrote: >> Not when dead store happens in an external DSO where compiler can't detect >> it (same applies for single references). > > Do you mean the ones between the DSO and the instrumented code? >

Good day! To get ready for the release, we need to make sure that the list of external open source projects using LLVM 3.0 (file:///Volumes/Sandbox/llvm/llvm.src/docs/ReleaseNotes.html#externalproj) is up to date. Please send me an email with the project's name and a short description of it. Alternatively, if the project was commented out and you would still like to be listed, just tell me

...licated, you could codegen it (in the background?) to a shlib next time you launch. If you want a persistent code cache that you can update incrementally, I think you'll need to come up with something that looks quite different from LLVM's JIT. Finally, this reminds me of the work done on DynamoRIO to persist application code caches for use between processes and after reloading the app: http://www.burningcutlery.com/derek/docs/procshared-VEE08.pdf They've had to solve some of the same problems. Reid On Wed, Feb 16, 2011 at 4:47 PM, Jochen Wilhelmy <j.wilhelmy at arcor.de> wrote:...

Hi! Is it possible to implement a byte code cache for a llvm-jit? This way the compile time occurs only once and the next time the compiled machine code can simply be loaded from disk. Of course care has to be taken with function pointers that are used as constants since they may change on the next run. -Jochen

...t; -bw >> > > Name: ThreadSanitizer, a data race detector. > Description: > ThreadSanitizer is a data race detector for (mostly) C and C++ code, > available for Linux, Mac OS and Windows. > On different systems we use binary instrumentation frameworks > (Valgrind, Pin and DynamoRio) as frontends that generate the program > events for the race detection algorithm. > On Linux there's an option of using LLVM-based compile-time instrumentation. > Oh, and the project page: http://code.google.com/p/data-race-test/

Hello, I'm executing my byte code program by the lli tool using mcjit. I need a way to find statistics about the number of instructions executed for my program. The -stats option does not include this value, are there any other way to know? I need this information to compare different versions of my bytecode program. Please advice Thanks in advance Sara Elsohbaky --------------

...t; But this brings the major issue as well: msan needs to see all program >> events, including system calls and reads/writes in system libraries, >> so we either need to compile *everything* with msan or use a binary >> translation component to instrument pre-built libraries (with DynamoRIO? >> PIN?). >> >> Question: is there any usable project in LLVM land which performs binary >> instrumentation (x86->LLVM->x86), either statically or dynamically? >> >> Another difference from Memcheck is that we propose to use 8 shadow bits >> per byte...

This might be a bit late, but I've got another argument for bundling zlib source with LLVM. Sanitizer tools need to symbolize stack traces in the reports. We've been using standalone symbolizer binary until now; sanitizer runtime spawns a new process as soon as an error is found, and communicates with it over a pipe. This is very cumbersome to deploy, because we need to keep another

Chris Lattner <clattner at apple.com> writes: >>> 1. It generates really slow build systems. >> >> In my Linux box, last time I checked (long time ago) the cmake build was >> a bit faster than the Makefiles. But this is a tricky terrain, because >> they are not identical, not on the features supported (and some have an >> impact on build-time) nor

On Oct 27, 2011, at 11:28 PM, Óscar Fuentes wrote: > Chris Lattner <clattner at apple.com> writes: > >> There are several major problems with CMake IMO: >> >> 1. It generates really slow build systems. > > In my Linux box, last time I checked (long time ago) the cmake build was > a bit faster than the Makefiles. But this is a tricky terrain, because >