|
From: Julian S. <js...@ac...> - 2006-06-03 11:46:44
|
On Saturday 03 June 2006 07:33, Nicholas Nethercote wrote: > On Sat, 3 Jun 2006, Eric Li wrote: > > But what I want is to use VEX as a library to generate IR and then use > > that IR in my own project. Initially, I thought VEX did just that and > > handed the IR over to the tools for further processing, but now it's > > clear to me that it only lets you define the instrumentation functions. > > "Defining the instrumentation functions" is exactly equivalent to "handing > over the IR for further processing". The instrumentation function is given > each BB's IR and can then do anything it wants to it (although if the end > result isn't functionally equivalent the program's behaviour will be > changed). One question is: do you really want to ship bits of IR off outside the Valgrind framework? Usually people want to mess with the IR and then run the results, which is precisely what the whole framework (Valgrind) exists for. It provides loads of useful infrastructure. I guess you could send the IR to an external tool for some kind of offline analysis, but once outside the Valgrind infrastructure it will be difficult to run the results. > > Would it be a fairly involved endeavor to take apart VEX and extract just > > the parts that generate the IR? > > AIUI that's really all Vex does. It has a couple of minor > Valgrind-specific hooks, but it should be usable standalone. Yes, it's very self-contained. VEX/test_main.c uses the main function (LibVEX_Translate) to deal with single BBs. VEX/switchback/switchback.c, despite being somewhat broken, is a simple dynamic-translation based program-runner based around Vex, in one file. (Both of these are for testing/debugging it.) J |