VEX's Makefile generates files pub/libvex_guest_offsets.h and priv/main/vex_svnversion.h. When VEX is made by valgrind's Makefile, these files are not properly updated. This can result in valgrind's output reporting an obsolete VEX revision; or in a CPU-bound loop requiring SIGKILL to terminate when OFFSET_x86_EIP is out of date. The following patches (one for VEX, one for valgrind) fix this problem. To test the change in VEX outside of valgrind and svn it was necessary to add auxprogs/genoffsets.c to VEX's minidist target. This file *is* included in valgrind's distribution.
Created attachment 12221 [details] Patch VEX's Makefile
Created attachment 12222 [details] Patch valgrind's coregrind/Makefile.am
I've applied your change to valgrind, along with another to declare the libvex.a target as phony so that we always try and rebuild it in case there are changes in the VEX code. This change is revision 4473. The VEX change is up to Julian - ideally the valgrind Makefile wouldn't need the vex_svnversion.h stuff at all as the VEX makefile would take care of (re)building that if required. The valgrind Makefile only has that because the VEX one doesn't have a dependency from libvex.a to vex_svnversion.h.
Sorry to report that the patch as applied does not work (revision 4850/1409). In file Makefile.tool.am (where the relevant information has been moved to), target @VEX_DIR@/priv/main/libvex_guest_offsets.h depends on nothing, meaning that this file, once it exists, will never be updated. As a result, target @VEX_DIR@/libvex.a is never updated. In the patch I submitted for coregrind/Makefile.am, I used $(wildcard @VEX_DIR@/.svn/entries) as dependency for @VEX_DIR@/priv/main/vex_svnversion.h to enforce timely updates of both targets, with this comment: # For those working in a local copy of the svn repository, '$(wildcard # .svn/entries)' evaluates to '.svn/entries', where the revision # number is stored. Hence priv/main/vex_svnversion.h is updated when # needed. For those working in an unpacked distribution, $(wildcard # .svn/entries) expands to an empty string. As # priv/main/vex_svnversion.h already exists in the distribution, # nothing is done. An alternative is to have @VEX_DIR@/priv/main/vex_svnversion.h depend on $(VEX_PRIMARY_SOURCES) $(VEX_PUBLIC_HDRS), if a way can be found to make the value of these variables (currently defined in file Makefile.am) available in all places where file Makefile.tool.am is included.
It doesn't work because Julian got rid of my phone declaration! It did work when I first applied it.
> ------- Additional Comments From tom compton nu 2005-10-03 22:04 ------- > It doesn't work because Julian got rid of my phone declaration! It did work > when I first applied it. Oh .. I think screwed this up. Sorry. I'll look at it shortly.
It might have been me, I removed a phony declaration because it was causing each tool to be rebuilt every time "make install" was executed, even though it wasn't necessary.
s/rebuilt/relinked/
In message <20051003211127.30936.qmail@ktown.kde.org> you wrote: > It might have been me, I removed a phony declaration because it was > causing each tool to be rebuilt every time "make install" was executed, > even though it wasn't necessary. I knew somebody had for some reason my memory said Julian... The point of the phony declaration is to force make to always be run in VEX in case there are any changes there. Presumably that was causing the libvex timestamp to change and hence the tools to relink? Tom
I just committed r10364 which properly integrates Vex into the autotools build. libvex_guest_offsets.h should always be generated properly now. vex_svnversion.h is generated when not present and regenerated upon 'make dist'. It can get out of date while developing if you update the Vex revision but this is difficult to avoid.