Bug 110770 - VEX: Generated files not always updated when making valgrind [PATCH]
Summary: VEX: Generated files not always updated when making valgrind [PATCH]
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: 3.0 SVN
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-14 17:32 UTC by Jeroen N. Witmond
Modified: 2009-06-24 03:13 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Patch VEX's Makefile (2.17 KB, patch)
2005-08-14 17:35 UTC, Jeroen N. Witmond
Details
Patch valgrind's coregrind/Makefile.am (917 bytes, patch)
2005-08-14 17:37 UTC, Jeroen N. Witmond
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeroen N. Witmond 2005-08-14 17:32:22 UTC
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.
Comment 1 Jeroen N. Witmond 2005-08-14 17:35:05 UTC
Created attachment 12221 [details]
Patch VEX's Makefile
Comment 2 Jeroen N. Witmond 2005-08-14 17:37:39 UTC
Created attachment 12222 [details]
Patch valgrind's coregrind/Makefile.am
Comment 3 Tom Hughes 2005-08-20 18:28:24 UTC
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.
Comment 4 Jeroen N. Witmond 2005-10-03 20:59:08 UTC
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.
Comment 5 Tom Hughes 2005-10-03 22:04:25 UTC
It doesn't work because Julian got rid of my phone declaration! It did work when I first applied it.
Comment 6 Julian Seward 2005-10-03 22:43:02 UTC
> ------- 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.
Comment 7 Nicholas Nethercote 2005-10-03 23:11:18 UTC
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.
Comment 8 Nicholas Nethercote 2005-10-03 23:15:38 UTC
s/rebuilt/relinked/
Comment 9 Tom Hughes 2005-10-04 01:12:35 UTC
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
Comment 10 Nicholas Nethercote 2009-06-24 03:13:26 UTC
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.