Some files for the freebsd port have not yet committed, but were
already referenced in the Makefiles. Remove those references for
now to make distcheck happy.
* coregrind/Makefile.am (valgrind_SOURCES): Remove
launcher-freebsd.c
* drd/tests/Makefile.am (check_PROGRAMS): Remove
thread_name_freebsd.
* none/tests/Makefile.am (SUBDIRS): Remove freebsd.
(DIST_SUBDIRS): Likewise.
* none/tests/freebsd/filter_stderr: Removed.
Files in the root directory
Several Makefile.am files that have dependencies on FreeBSD autoconf
variables. Included a few new filter files to act as placeholders
to create new freebsd subdirectories.
Updated NEWS with the FreeBSD bugzilla items plus a couple of other
items fixed indirectly.
vglibdir is the directory from where valgrind loads its internal tool
executables and vgpreloads. Currently vglibdir is pkglibdir, so those
internal tools are intermingeled with normal executables and libraries
that the user might use directly.
Make vglibdir equal to pkglibexecdir so the internal tools get installed
and loaded from libexec and don't get get stored under lib.
This leaves just the static archives and the mpiwrapper libraries that
the user would link/load themselves under pkglibdir.
This seems more in line with the FHS lib/libexec standard and makes it
slightly easier to combine the tools from a multilib target (say the
memcheck-amd64-linux and memcheck-x86-linux tools) because they would
be installed under the same directory, while the pkglibdir can differ
depending on arch/target (lib/lib64).
https://bugs.kde.org/show_bug.cgi?id=433323
debuginfod is an HTTP server for distributing ELF/DWARF debugging
information. When a debuginfo file cannot be found locally, Valgrind
is able to query debuginfod servers for the file using its build-id.
readelf.c: Add debuginfod_find_debug_file(). Spawns a child process to
exec `debuginfod-find` in order to query servers for the debuginfo
file. Also add helper debuginfod_find_path().
pub_core_pathscan.h: Moved from priv_initimg_pathscan.h in order to use
VG_(find_executable)() in readelf.c.
docs: Add information regarding debuginfod to valgrind.1
memcheck/tests/linux: Add new test debuginfod-check.
tests/vg_regtest.in: Clear $DEBUGINFOD_URLS before running any tests.
https://bugs.kde.org/show_bug.cgi?id=432215
Provide a new library libgcc-sup-<platform>.a that contains symbols
needed by libgcc. This needs to be linked after -lgcc to provide
any symbols missing which would normally be provided by glibc.
At the moment this only provides __getauxval on arm64 linux.
https://bugs.kde.org/show_bug.cgi?id=421321
Necessary changes to support nanoMIPS on Linux.
Part 2/4 - Coregrind changes
Patch by Aleksandar Rikalo, Dimitrije Nikolic, Tamara Vlahovic and
Aleksandra Karadzic.
Related KDE issue: #400872.
The primary and secondary coregrind libraries must be updated
when m_main.c or m_libcsetjmp.c are changed.
A dependency was missing between libcoregrind*.a and libnolto_coregrind*.a,
and so tools were not relinked when m_main.c or m_libcsetjmp.c were
changed.
* Addition of a new configure option --enable-lto=yes or --enable-lto=no
Default value is --enable-lto=no, as the build is significantly slower,
so is not appropriate for valgrind development : this should be used
only on buildbots and/or by packagers.
* Some files containins asm functions have to be compiled without lto:
coregrind/m_libcsetjmp.c
coregrind/m_main.c
If these are compiled with lto, that gives undefined symbols at link time.
The files to compile without lto are
coregrind/m_libcsetjmp.c
coregrind/m_main.c
To compile these files with other options, a noinst target lib is defined.
The objects of this library are then added to the libcoregrind.
* memcheck/mc_main.c : move the handwritten asm helpers to mc_main_asm.c.
This avoids undefined symbols on some toolchains. Due to this,
the preprocessor symbols that activate the fast or asm memcheck helpers
are moved to mc_include.h
Platforms with handwritten helpers will also have the memcheck primary
map defined non static.
* In VEX, auxprogs/genoffsets.c also has to be compiled without lto,
as the asm produced by the compiler is post-processed to produce
pub/libvex_guest_offsets.h. lto not producing asm means the generation
fails if we used -flto to compile this file.
* all the various Makefile*am are modified to use LTO_CFLAGS for
(most) targets. LTO_CFLAGS is empty when --enable-lto=no,
otherwise is set to the flags needed for gcc.
If --enable-lto=no, LTO_AR and LTO_RANLIB are the standard AR and RANLIB,
otherwise they are the lto capable versions (gcc-ar and gcc-ranlib).
* This has been tested on:
debian 9.4/gcc 6.3.0/amd64+x86
rhel 7.4/gcc 6.4.0/amd64
ubuntu 17.10/gcc 7.2.0/amd64+x86
fedora26/gcc 7.3.1/s390x
No regressions on the above.
Update the libiberty demangler using the auxprogs/update-demangler
script to the gcc svn r246502 revision. Replaces our rust demangling
with the upstream variant (which is basically the same code in a
separate file). Adds handling of inheriting constructor. Handle
noexcept and throw-spec. Demangle Dc as decltype(auto). And various
(crasher) bug fixes.
Bug 378673.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16302
This commit is the bulk of the new code.
There is however no functional impact yet : the new modules are not used by anybody.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16123
Update the libiberty demangler using the auxprogs/update-demangler
script. There were various extensions and bug fixes since our last
import. Add new D language demangler file d-demangle.c and update
the vg_libciface.h header with some new constructs used (strtol,
xmalloc_failed, xmemdup, XDELETEVEC, XDUPVEC).
Resolves bug #359181 - Buffer Overflow during Demangling.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15951
- zlib ELF gABI format with SHF_COMPRESSED flag (gcc option -gz=zlib)
- zlib GNU format with .zdebug sections (gcc option -gz=zlib-gnu)
Patch by: Aleksandar Rikalo <aleksandar.rikalo@imgtec.com>
Fixes BZ#303877
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15868
correctly
1) Fix Endianess issue that was missed in the BE to LE port. GDB was
not displaying the contents of the 64-bit and 128-bit registers
correctly due to an Endianess issue.
2) Fix displaying the shadow registers for the 64-bit and 128-bit
registers.
Bugzilla 360008 was opened for this issue.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15864
one for Darwin. Down from 11.
Carve out a new function 'track_frame_memory' that communicates to the
tool the allocation of a new stack frame. This was slightly different on
Linux and Darwin but should be the same on both platforms.
New files: priv_sigframe.h and sigframe-common.c
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15109
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
putting them into a string table.
This patch adds reference counting to segment names and frees them
when they are no longer used. The so freed memory can be reclaimed to
store future segment names.
New file coregrind/m_aspacemgr/aspacemgr-segnames.c which has all the
code dealing with segment names. Carved out of aspacemgr-linux.c
Detailled comments in the code.
Fixes BZ 344559.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15073
- 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
of __PAGEZERO to zero. Without this, the 10.10 kernel refuses to
start these executables. Based on investigations and a
proof-of-concept implementation by Rhys Kidd (rhyskidd@gmail.com).
Part of bug 339045.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14697
includes libvex.h. It isn't needed to successfully compile pub_core_basics.h
standalone and the declarations libvex.h provides aren't used as broadly as
the comment in the code implied.
Move the guest-specific includes and some ifdeffery to the new file
pub_core_guest.h
For the curious reader: The change above avoids a problem when linking the
linux-launcher which previously included libvex.h indirectly. libvex.h also
defines the inline function LibVEX_Alloc which, when emitted, causes the
link step to fail due to unresoled references (as the launcher does not link
against libvex.a). See also BZ #339542.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14600
Since valgrind 3.9.0 the STABS support was already disabled completely.
But the code was still there being compiled and we were still searching
for stabs sections in binaries. Completely remove all sources, tests and
references. Add a note to coregrind/m_debuginfo/README.txt to mention
the old code can be found in the subversion repository.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14550
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
to add PPC64 LE support. The other two patches can be found in Bugzillas
334384 and 334836.
POWER PC, add the functional Little Endian support, patch 2
The IBM POWER processor now supports both Big Endian and Little Endian.
The ABI for Little Endian also changes. Specifically, the function
descriptor is not used, the stack size changed, accessing the TOC
changed. Functions now have a local and a global entry point. Register
r2 contains the TOC for local calls and register r12 contains the TOC
for global calls. This patch makes the functional changes to the
Valgrind tool. The patch makes the changes needed for the
none/tests/ppc32 and none/tests/ppc64 Makefile.am. A number of the
ppc specific tests have Endian dependencies that are not fixed in
this patch. They are fixed in the next patch.
Per Julian's comments renamed coregrind/m_dispatch/dispatch-ppc64-linux.S
to coregrind/m_dispatch/dispatch-ppc64be-linux.S Created new file for LE
coregrind/m_dispatch/dispatch-ppc64le-linux.S. The same was done for
coregrind/m_syswrap/syscall-ppc-linux.S.
Signed-off-by: Carl Love <carll@us.ibm.com>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14239
include/pub_tool_deduppoolalloc.h
coregrind/pub_core_deduppoolalloc.h
coregrind/m_deduppoolalloc.c
and uses it (currently only) for the strings in m_debuginfo/storage.c
The idea is that such ddup pool allocator will also be used for other
highly duplicated information (e.g. the DiCFSI information), where
significant gains can also be achieved.
The dedup pool for strings also decreases significantly the memory
needed by the read inline information (patch still to be committed,
see bug 278972).
When testing with a big executable (tacot_process),
this reduces the size of the dinfo arena from
trunk: 158941184/109760512 max/curr mmap'd, 156775944/107882728 max/curr,
to
ddup: 157892608/106614784 max/curr mmap'd, 156362160/101414712 max/curr
(so 3Mb less mmap-ed once debug info is read, 1Mb less mmap-ed in peak,
6Mb less allocated once debug info is read).
This is all gained due to the string which changes from:
trunk: 17,434,704 in 266: di.storage.addStr.1
to
ddup: 10,966,608 in 750: di.storage.addStr.1
(6.5Mb less memory used by strings)
The gain in mmap-ed memory is smaller due to fragmentation.
Probably one could decrease the fragmentation by using bigger
size for the dedup pool, but then we would lose memory on the last
allocated pool (and for small libraries, we often do not use much
of a big pool block).
Solution might be to increase the pool size but have a "shrink_block"
operation. To be looked at in the future.
In terms of performance, startup of a big executable (on an old pentium)
is not influenced significantly (something like 0.1 seconds on 15 seconds
startup for a big executable, on a slow pentium).
The dedup pool uses a hash table. The hash function used currently
is the VG_(adler32) check sum. It is reported (and visible also here)
that this checksum is not a very good hash function (many collisions).
To have statistics about collisions, use --stats -v -v -v
As an example of the collisions, on the strings in debug info of memcheck tool on x86,
one obtain:
--4789-- dedupPA:di.storage.addStr.1 9983 allocs (8174 uniq) 11 pools (4820 bytes free in last pool)
--4789-- nr occurences of chains of len N, N-plicated keys, N-plicated elts
--4789-- N: 0 : nr chain 6975, nr keys 0, nr elts 0
--4789-- N: 1 : nr chain 3670, nr keys 6410, nr elts 8174
--4789-- N: 2 : nr chain 1070, nr keys 226, nr elts 0
--4789-- N: 3 : nr chain 304, nr keys 100, nr elts 0
--4789-- N: 4 : nr chain 104, nr keys 84, nr elts 0
--4789-- N: 5 : nr chain 72, nr keys 42, nr elts 0
--4789-- N: 6 : nr chain 44, nr keys 34, nr elts 0
--4789-- N: 7 : nr chain 18, nr keys 13, nr elts 0
--4789-- N: 8 : nr chain 17, nr keys 8, nr elts 0
--4789-- N: 9 : nr chain 4, nr keys 6, nr elts 0
--4789-- N:10 : nr chain 9, nr keys 4, nr elts 0
--4789-- N:11 : nr chain 1, nr keys 0, nr elts 0
--4789-- N:13 : nr chain 1, nr keys 1, nr elts 0
--4789-- total nr of unique chains: 12289, keys 6928, elts 8174
which shows that on 8174 different strings, we have only 6410 strings which have
a unique hash value. As other examples, N:13 line shows we have 13 strings
mapping to the same key. N:14 line shows we have 4 groups of 10 strings mapping to the
same key, etc.
So, adler32 is definitely a bad hash function.
Trials have been done with another hash function, giving a much lower
collision rate. So, a better (but still fast) hash function would probably
be beneficial. To be looked at ...
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14029
This only works in non-bi arch mode. If ever aarch64+arm
are compiled bi-arch, then some more work is needed to have
a 64 bits vgdb able to ptrace invoke a 32 bits valgrind.
Note also that PTRACE_GETREGSET is defined on other platforms
(e.g. ppc64 fedora 18 defines it), but it is not used on
these platforms, as again, PTRACE_GETREGSET implies some
work for bi-arch to work properly.
So, on all platforms except arm64, we use PTRACE_GETREGS
or PTRACE_PEEKUSER.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13981
of memcheck and helgrind in a common module:
pub_tool_addrinfo.h pub_core_addrinfo.h m_addrinfo.c
At the same time, the factorised code is made usable by other
tools also (and is used by the gdbserver command 'v.info location'
which replaces the helgrind 'describe addr' introduced 1 week ago
and which is now callable by all tools).
The new address description code can describe more addresses
(e.g. for memcheck, if the block is not on the free list anymore,
but is in an arena free list, this will also be described).
Similarly, helgrind address description can now describe more addresses
when --read-var-info=no is given (e.g. global symbols are
described, or addresses on the stack are described as
being on the stack, freed blocks in the arena free list are
described, ...).
See e.g. the change in helgrind/tests/annotate_rwlock.stderr.exp
or locked_vs_unlocked2.stderr.exp
The patch touches many files, but is basically a lot of improvements
in helgrind output files.
The code changes are mostly refactorisation of existing code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13965
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
VALGRIND_DISABLE_ADDR_ERROR_REPORTING_IN_RANGE and
VALGRIND_ENABLE_ADDR_ERROR_REPORTING_IN_RANGE
and supporting machinery for managing whole-address-space sparse
mappings. n-i-bz. In support of
https://bugzilla.mozilla.org/show_bug.cgi?id=970643
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13884
vgdb.c contained (conditionally compiled) "invoker" code to have ptrace syscalls
used to allow gdb/vgdb to connect to a valgrind process blocked in a syscall.
This "invoker" code is ptrace based.
Not all platforms are using ptrace.
=> refactor vgdb so as allow invoker code to be added more cleanly
for non ptrace based platforms (e.g. Darwin, Solaris).
* add file vgdb.h for:
- definition of the vgdb-invoker interface
- common declarations between vgdb.c and vgdb-invoker implementations
* move ptrace related code from vgdb.c to new file vgdb-invoker-ptrace.c
* new file vgdb-invoker-none.c containing an empty invoker implementation
used on platforms that do not (yet) have a invoker implementation
(e.g. android and darwin).
* modified Makefile.am to use one of the vgdb-invoker-*.c file depending
on the platform.
* small changes related to changing ptraceinvoker to invoker in various files:
gdbserver_tests/make_local_links, gdbserver_tests/nlcontrolc.vgtest,
gdbserver_tests/mcinvokeRU.vgtest, gdbserver_tests/nlsigvgdb.vgtest
gdbserver_tests/mcinvokeWS.vgtest, coregrind/m_gdbserver/README_DEVELOPERS
Patch from Ivo Raisr, slightly modified
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13743
