following improvements:
- Arch/OS/platform-specific files are now included/excluded via the
preprocessor, rather than via the build system. This is more consistent
(we use the pre-processor for small arch/OS/platform-specific chunks
within files) and makes the build system much simpler, as the sources for
all programs are the same on all platforms.
- Vast amounts of cut+paste Makefile.am code has been factored out. If a
new platform is implemented, you need to add 11 extra Makefile.am lines.
Previously it was over 100 lines.
- Vex has been autotoolised. Dependency checking now works in Vex (no more
incomplete builds). Parallel builds now also work. --with-vex no longer
works; it's little use and a pain to support. VEX/Makefile is still in
the Vex repository and gets overwritten at configure-time; it should
probably be renamed Makefile-gcc to avoid possible problems, such as
accidentally committing a generated Makefile. There's a bunch of hacky
copying to deal with the fact that autotools don't handle same-named files
in different directories. Julian plans to rename the files to avoid this
problem.
- Various small Makefile.am things have been made more standard automake
style, eg. the use of pkginclude/pkglib prefixes instead of rolling our
own.
- The existing five top-level Makefile.am include files have been
consolidated into three.
- Most Makefile.am files now are structured more clearly, with comment
headers separating sections, declarations relating to the same things next
to each other, better spacing and layout, etc.
- Removed the unused exp-ptrcheck/tests/x86 directory.
- Renamed some XML files.
- Factored out some duplicated dSYM handling code.
- Split auxprogs/ into auxprogs/ and mpi/, which allowed the resulting
Makefile.am files to be much more standard.
- Cleaned up m_coredump by merging a bunch of files that had been
overzealously separated.
The net result is 630 fewer lines of Makefile.am code, or 897 if you exclude
the added Makefile.vex.am, or 997 once the hacky file copying for Vex is
removed. And the build system is much simpler.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10364
I tried using 'svn merge' to do the merge but it did a terrible job and
there were bazillions of conflicts. So instead I just took the diff between
the branch and trunk at r10155, applied the diff to the trunk, 'svn add'ed
the added files (no files needed to be 'svn remove'd) and committed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10156
the DARWIN branch easier later.
- Remove the disabled vgtest_ume test, it's very unlikely it'll ever work
again.
- Move VG_(find_auxv) to initimg-linux.c, the only place it's used, and make
it static.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9004
suggested in #119404.
Prior to this commit, if the current traced process attempted to
execve a setuid executable, an error was always returned. The revised
behaviour is:
If the current (traced) process attempts to execve a setuid
executable:
* If --trace-children=yes is not in effect, the execve is allowed.
* If --trace-children=yes is in effect, the execve is disallowed
(as at present), but an error message is printed (unless in XML mode),
so at least the execve does not fail silently any more.
As per discussion on #119404 we could probably do a lot better, but
these changes are at least simple, useful and uncontroversial.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7175
Track SysRes change, and remove unused stuff in header. Perhaps
this should be folded into m_initimg in the fullness of time.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6286
checking of programs done in these two places are combined, which avoids
duplicate code and greatly reduces the number of cases in which exec()
fails causing Valgrind to bomb out.
Also, we can now load some programs we could not previously, such as scripts
lacking a "#!" line at the start. Also, the startup failure messages for
bad programs match the shell's messages very closely.
And I added a whole bunch of regtests to test all this.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4918
changes from r4341 through r4787 inclusive). That branch is now dead.
Please do not commit anything else to it.
For the most part the merge was not troublesome. The main areas of
uncertainty are:
- build system: I had to import by hand Makefile.core-AM_CPPFLAGS.am
and include it in a couple of places. Building etc seems to still
work, but I haven't tried building the documentation.
- syscall wrappers: Following analysis by Greg & Nick, a whole lot of
stuff was moved from -generic to -linux after the branch was created.
I think that is satisfactorily glued back together now.
- Regtests: although this appears to work, no .out files appear, which
is strange, and makes it hard to diagnose regtest failures. In
particular memcheck/tests/x86/scalar.stderr.exp remains in a
conflicted state.
- amd64 is broken (slightly), and ppc32 will be unbuildable. I'll
attend to the former shortly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4789
namespace pollution.
Also broadened a couple of _dl_* suppressions so that vgtest_ume
passes on my machine.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3993
