|
From: Yan <ya...@ya...> - 2015-03-29 21:28:27
|
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. - Yan [1] http://github.com/zardus/pyvex [2] http://www.internetsociety.org/doc/firmalice-automatic-detection-authentication-bypass-vulnerabilities-binary-firmware [3] https://github.com/zardus/pyvex/blob/master/patches/valgrind_static_3.9.0.patch On Sun, Mar 29, 2015 at 1:16 PM, Philippe Waroquiers < phi...@sk...> wrote: > On Sun, 2015-03-29 at 22:46 +0200, Florian Krohm wrote: > > Julian can give the full history. > > There is plenty of evidence that the original VEX design goal was to > > support host != guest. But when I began looking at V code in 2006 the > > code wasn't clean in that respect. And it hasn't gone any better. > > Here is a quote from Julian from Dec 2014 clarifying: > > > > This guest-vs-host stuff is still partly alive as a result of a > > hope I had that someone might want to do a cross-valgrind one day, > > eg ARM32 guest on AMD64 host. But it's been 12+ years and I've > > never once heard any mention of such a thing. So perhaps it's > > time to give up on that one. > > > > I think that settles your question :) > Yes :). > > > > > If VEX host and guest are in any case supposed to be the same, > > > then solution 1 is the easiest. > > > > Yes. > > > > It's funny.. I looked at this very same issue a few weeks back but could > > not figure out the autotools stuff. > > Note, though, that we still want to compile all VEX sources and not just > > the ones pertaining to the current architecture. > Yes, for sure, that is the idea. > I am busy now doing the solution 1. > I have already eliminated s390 :). > > Philippe > > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |