This is getting rediculous. We need a better way to compare
backtraces in regression test outputs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5575
distinction between primary and secondary build targets, and (2) make
it independent of the default behaviour of gcc (iow, what gcc does
when you specify neither -m32 nor -m64).
As a result, an out-of-the-box build on ppc64-linux now builds a
system which is basically for 64-bit PowerPC, but also has the ability
to run 32-bit ppc-linux binaries (exactly the same arrangement as you
get when building on amd64-linux).
There are various twists and turns. multiple-architectures.txt is
updated all the gory details.
This will break amd64 builds until such time as
<tool>/tests/{amd64,x86}/Makefile.am are fixed up (shortly).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5493
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
get included in the distro now, not just the ones for the arch/platform
that the distro tarball is built on.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4085
no real point in having them in corecheck/tests since they're not testing
anything that Nulgrind doesn't provide.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4048
overhaul of the thread support. Many things are now probably broken,
but at least with --tool=none, simple and not-so-simple threaded and
non-thread programs work.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3265
which list all the arches/OSes/platforms supported. These are used by
several newly added DIST_SUBDIRS automake commands, which specify that
although when you are building you only want to build for the current
arch/OS/platform, when you do 'make dist' you want every
arch/OS/platform to get included.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3127
multiple of the page size had an off by one error. Fixed it to use
the PGROUNDUP macro instead of trying to do the calculation itself
and then get it wrong.
BUG: 93309
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3030
- Moved all the insn_* tests into x86/ subdirectories. What are the chances of
me getting this right on the first attempt?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2809
can block (ie F_SETLKW) are treated as blocking.
This resolves the F_SETOWN problem described in bug #85969.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2535
the current reserved area, which effectively acts as a hard limit. The
setrlimit system call now simply updates the emulated limits as best
as possible - the hard limit is not allowed to move at all and just
returns EPERM if you try and change it.
This should stop reductions in the soft limit causing assertions when
valgrind tries to allocate descriptors from the reserved area.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2440
the execve system call if the envp pointer is null as it causes
valgrind to die with a segmentation fault.
CCMAIL: 83573-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2427
- If no tool is specified, V now gives a short message and a list of
available tools. This was meant to happen previously, but a bug prevented
it from working properly; it gave the usage message instead.
- If a bad option is given, V now gives a short message rather than the full
--help. This make V consistent with all other programs I looked at.
- Now returning 0 when you do 'valgrind --help' and 'valgrind --version'
as other programs do.
- Removed VG_(startup_logging)() and VG_(shutdown_logging)() as they were
empty and have been for a long time (always?).
- Added various tests for these scenarios. Had to change the regtest
script slightly to allow for malformed command lines.
This addresses bug (wishlist) #82999.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2418
