|
From: Philippe W. <phi...@sk...> - 2015-03-29 22:19:34
|
On Sun, 2015-03-29 at 14:27 -0700, Yan wrote: > Hi guys, > > > We use VEX pretty heavily in research here at UC Santa Barbara > (resulting in PyVEX [1] and some published [2] and in-submission > academic papers), and for us, the ability to handle multiple > architectures with the same libVEX is really crucial. As it is > already, we have to patch VEX pretty heavily (see the patch in [3]) to > get it to work statically, but the changes in option 1 sound like > they'll make things even worse for us :-( > > > Of course, no one's under any obligation to make our lives over here > easier. In fact, I talked to Philippe and Julian at FOSDEM '14 about > me sending in some patches to change up the VEX interface to be more > flexible (basically, option 3) and Julian seemed receptive at the > time. However, with PhD stuff, grant progress reports, and paper > deadlines, I haven't had any time to actually do it. If it saves > multi-arch VEX, though, we can make it a top priority over here and > devote a few good guys to it to get it done... > > > So, in summary, if option 3 could be made more attractive with some > manpower, UCSB can provide that manpower, because we use VEX in a > multi-arch, static way for our research. Isn't option 2 good enough ? I just finished implementing option 1. In option 1, we have the following comment: /* For each architecture <arch>, we define 2 macros: <arch>FN that has as argument a pointer to a function. <arch>ST that has as argument a statement. If VEX is compiled for <arch>, then these macros just expand their arg. Otherwise, the macros expands to respectively NULL and vassert(0). These macros are used to avoid introducing dependencies to object files not needed for the (only) architecture we are compiling for. To still compile the below for all supported architectures, define VEXMULTIARCH. */ // #define VEXMULTIARCH 1 So, a very trivial patch is enough to have VEX compiled in multiarch with option 1. Of course, option 2 now only means adding a configure option. If needed, we could maybe have option 2.5: We compile main_main.c twice: One with VEXMULTIARCH not defined to produce an object main_main.o and one with VEXMULTIARCH defined to produce another object multi_arch_main_main.o Then, I suppose that when linking, if you put multi_arch_main_main.o before the VEX library .a, that the linker will choose multi_arch_main_main.o to resolve the needed LibVEX functions defined in main_main.c Philippe |