Make sure to include the builddir include directory to find the
generated vgversion.h. Make include/vgversion.h a .PHONY target
so it always gets regenerated even if the file is already there.
Make sure to run svnversion in the srcdir.
Patch by Matthias Schwarzott <zzam@gentoo.org>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16397
largefile support by default. This gets in the way what
Valgrind core expects (vki, various m_libc modules).
Therefore disable largefile support if it is enabled.
Anyway, support for 32-bit applications is going away in Solaris 12.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15785
We want to disabled Identical Code Folding for the tools preload shared
objects to get better backraces. For GCC 5.1 -fipa-icf is enabled by
default at -O2.
The optimization reduces code size and may disturb
unwind stacks by replacing a function by equivalent
one with a different name.
Add a configure check to see if GCC supports -fno-ipa-icf.
If it does then add the flag to AM_CFLAGS_PSO_BASE.
Without this GCC will notice some of the preload replacement functions
in vg_replace_strmem are identical and fold them all into one picking
a random (existing) function name. This causes backtraces showing
completely unexpected function names.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15305
Valgrind aspects, to match vex r3124.
See bug 339778 - Linux/TileGx platform support to Valgrind
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15080
- add configure option --enable-ubsan
- add __ubsan helpers (by Julian)
This requires gcc 4.9.2 or later. Not all platforms are supported, though.
With this change and VEX r3099 regression tests pass on amd64
with a valgrind compiled with -fsanitize=undefined.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14995
This was not as straight forward as expected. Specifically, adding the
new flag to CFLAGS in configure.ac did not work and was causing
compiler warnings. For instance, compiling memcheck/tests/execve2.c will
generate a -Wnonnull warning even though the testcase is explicitly
compiled with -Wno-nonnull. The reason is that (a) -Wformat is implied by
-Wnonnull and (b) the list of compiler flags gets assembled in the wrong
order. The culprit appears to be that we modify CFLAGS in configure.ac and
that really is not the right place. Conceptually, configure should determine
tool-chain capabilities and not assemble compiler flags. That should be done
in Makefiles. This patch entangles all this.
So, whatever was added to CFLAGS in configure.ac has now been moved to
Makefile.all.am and Makefile.tool-tests.am. Those are:
-Wno-long-long
-Wwrite-strings
-Wcast-qual
-fno-stack-protector
Note, that this change allows us to simplify Makefile.tool-tests.am which
in the past was disabling some of those flags (e.g. by adding -Wno-cast-qual
again).
In case of the clang compiler, extra command line options are needed. I've
moved those into a separate 'if COMPILER_IS_CLANG' section and not merge
them into baseline flags.
Related to BZ 334727.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14798
as opposed to the valgrind code proper. In particular, make sure that
-mpreferred-stack-boundary=2 does not get used for the preload shared
objects, since that can cause the stack to become misaligned and leads
to segfaults. Modified version of a patch from Matthias Schwarzott
(zzam@gentoo.org). Fixes#324050.
Also, fix the configure check in configure.ac for
-mpreferred-stack-boundary=2 so that it checks whether this is
allowable for 32-bit code generation even on 64-bit (x86) hosts. This
check was wrong before now and led to 32-bit builds on 64-bit hosts
generating poorer code for speed critical helper functions (eg
helperc_LOADV32le) than on 32-bit builds on 32-bit hosts.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14471
A performance regression was found due to the
-02 -m64 flags not being included when compiling
the VEX PPC64 code. This commit fixes the Makefile
to pass the needed flags when compiling VEX PPC64
code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14246
to add PPC64 LE support. The other two patches can be found in Bugzillas
334834 and 334836. The commit does not have a VEX commit associated with it.
POWER PC, add initial Little Endian support
The IBM POWER processor now supports both Big Endian and Little Endian.
This patch renames the #defines with the name ppc64 to ppc64be for the BE
specific code. This patch adds the Little Endian #define ppc64le to the
Additionally, a few functions are renamed to remove BE from the name if the
function is used by BE and LE. Functions that are BE specific have BE put
in the name.
The goals of this patch is to make sure #defines, function names and
variables consistently use PPC64/ppc64 if it refers to BE and LE,
PPC64BE/ppc64be if it is specific to BE, PPC64LE/ppc64le if it is LE
specific. The patch does not break the code for PPC64 Big Endian.
The test files memcheck/tests/atomic_incs.c, tests/power_insn_available.c
and tests/power_insn_available.c are also updated to the new #define
definition for PPC64 BE.
Signed-off-by: Carl Love <carll@us.ibm.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14238
is accepted. With XCode 5.5.1 -Wtautological-compare appears to come
as standard, and it generates a lot of mostly useless noise.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14136
Patch by Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>.
Partial fix. make && make check now works with builddir != srcdir.
But make regtest doesn't yet.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13949
During configuration of Valgrind we check does the compiler support -march=mips32 and
-march=mips64. If compiler supports these flags we are using them as default flags for
mips32 and mips64.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13815
Necessary changes to Valgrind to support MIPS64LE on Linux.
Minor cleanup/style changes embedded in the patch as well.
The change corresponds to r2687 in VEX.
Patch written by Dejan Jevtic and Petar Jovanovic.
More information about this issue:
https://bugs.kde.org/show_bug.cgi?id=313267
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13292
this has been the preferred way to compile for quite a while. So let's follow
suit. The perf bucket did not reveal any measurable difference.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12572
gcc 4.4 and 4.5 has a bug which causes miscompilation of mc_main.c:
args are not correctly given to VG_(am_munmap_valgrind).
This causes the secondary map entries to not be unmapped
(which can cause unlimited memory growth)
and/or causes the assert on VG_(am_munmap_valgrind) result to fail.
Removing the pragma optimize from mc_main.c and inserting it instead
in Makefile.all.am for x86 solves the gcc bug.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12564
in .S files. Also included here is some cleanup, including a reversion
of r10378. Fixes bugzilla #197914.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12555
idiom-recognition optimisation. This identifies memset-style
loops and turns them into calls to memset, which in this case
leads to infinite recursion because it does this transformations
in VG_(memset), which is called from memset(), which we also define.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12065
qualification of the normal (arch, os) pairings used to factorise the
code base via the VGP_ defines. With this change, a new define
VGPV_<arch>_<os>_<variant> is also passed to each compile. The
initial motivation is to allow clean factorisation of Android-specific
code, which is a minor variant of arm-linux, without having to
introduce a complete new platform. In all other cases the supplied
tag is simply "vanilla".
Also add configure.in stuff to recognise Android at configure time.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11872
accept the armv6t2 (I think) insns (movt, movw) in
dispatch-arm-linux.S. Some older gccs apparently think they are
compiling for armv6 by default and reject them (gcc 4.4.1 on Ubuntu
9.10, for one.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11793
side components. (Florian Krohm <britzel@acm.org> and Christian
Borntraeger <borntraeger@de.ibm.com>). Fixes#243404.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11604
svn merge -r11143:HEAD svn://svn.valgrind.org/valgrind/branches/MACOSX106
There were some easy-to-resolve conflicts.
Then I had to fix up coregrind/link_tool_exe*.in -- those files had been
added independently on both the trunk and the branch, AFAICT. I just
overwrote the trunk versions with the branch versions.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11194
executables. Gets rid of the linker script kludgery and uniformly
uses -Ttext=0x38000000 (or whatever) on Linux, so as to accomodate
both traditional ld and gold. Should fix#193413 although I have
been unable to test it. Using a whole new program seems like
overkill, but this is infrastructure to support static linking of
the tool executables on MacOS too.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11141
the changes to do with reading and using ELF and DWARF3 info.
This breaks all targets except amd64-linux and x86-linux.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10982
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
