Re: [Valgrind-developers] external users of VEX (was: NEWS, new features, fixed bugs : when to update NEWS)

[Stephen M. <sm...@al...>]

>>>>> "Y" == Yan  <ya...@ya...> writes:

Y> So I'm rather new to the list, and VEX development in general, but
Y> I wanted to chime in. Feel free to ignore me.

Y> I've been using VEX for static analysis, and am putting together a
Y> set of patches to make VEX more usable to this goal. However, my
Y> stuff is purely using VEX, not Valgrind, as the latter is
Y> completely geared for dynamic analysis. If there's interest in
Y> keeping VEX friendly for such uses, merging the VEX and Valgrind
Y> repositories would be counter-productive to that goal.

Y> In the security realm, there are a few projects (specifically, Vine
Y> and BAP) that forked VEX several years back to do non-Valgrind
Y> things with it.  While it might be too late for BAP and Vine, I
Y> think keeping VEX in a separate repository (and maybe even
Y> individualizing VEX and Valgrind slightly more) could encourage
Y> future projects like these to keep upstreaming their changes, as
Y> opposed to forking off on their own.

I wouldn't call Vine's use of VEX (or BAP's, which has been similar
though I think they're moving away from it) a fork. We do have a few
patches that we haven't gotten merged (cf.

  https://github.com/bitblaze-fuzzball/fuzzball/blob/master/vex-r2737.patch

), but Vine mostly wraps around VEX with new code to get something
that's more suitable for non-Valgrind purposes.

If there was a larger community of people building non-Valgrind tools
from VEX, there would be some value on collaborating more closely, but
I don't know if Yan's project plus Vine is yet getting close to a
critical mass.

I think from my perspective the layout of the repository is not a
critical factor. Doing a larger "svn checkout" but then ignoring most
of it would not be a major burden. Changing the build process so that
it's necessary to build all of Valgrind would make other uses a bit
slower, but there's a recurring inconsistency problem with the current
two separate build processes so it might not be a loss overall.

Obviously keeping VEX compiling as a separate library is important for
external users, but I don't see anyone proposing to change that.
Conversely external uses would be easier if VEX's interface were more
stable (our code has a lot of #if VEX_VERSION > xxxx directives).  But
as long as Valgrind is by far the predominant use of VEX I think us
external users are getting a pretty good deal.

 -- Stephen