_VKI_IOC_TYPECHECK() macro") in a way which is easier to understand.
Also, add it for arm-linux.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10990
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
- Made sure that C++ compilers do not complain about the header files
include/pub_tool_libcassert.h and include/pub_tool_basics.h.
- Added the source file none/tests/valgrind_cpp_test.cpp. This source file
is compiled together with the regression tests in order to verify that
Valgrind's public header files compile cleanly with a C++ compiler.
These modifications are based on a patch provided by Konstantin Serebryany.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10970
type STT_GNU_IFUNC which, instead of pointing directly at the
function, point at a routine which will return the address of
the real function. Redirection of indirect functions is handled
by valgrind as follows:
- When a redirection specification matches an indirect
function symbol an active redirection is added in the
normal way, but with the isIFunc flag set.
- When a call is made to an address which matches an
active redirection with the isIFunc flag set the call
is redirected, but not to the target address of the
redirection - instead it is sent to a small wrapper
routine that is preloaded into the client.
- The wrapper routine calls the original client routine
and collects the result, which it reports to valgrind
using a client request, and then returns the result to
the caller.
- When valgrind gets the client request it looks up the
active redirection for the indirect function and then
adds a new active redirection which redirects from the
address returned by the indirection function to the
redirection target. This new redirection does not have
the isIFunc flag set so behaves as a normal redirection.
In addition to the above we also add a few new redirections to
memcheck to capture internal calls made by glibc to things like
strlen, as these internal calls do not go through the indirect
function and instead go direct to the chosen implementation.
Based on a patch from Dodji Seketeli and comments from Jakub
Jelinek, this commit closes bug 206013.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10920
both wrapped up in XML tags (as before) but also in plain text in a
sequence of CDATA blocks. Normally only one, but in the worst case
the raw data will have ]]> in it, in which case it needs to be split
across two CDATA blocks.
This apparently simple change involved a lot of refactoring of the
suppression printing machinery:
* in the core-tool iface, change "print_extra_suppression_info" (which
prints any auxiliary info) to "get_extra_suppression_info", which
parks the text in a caller-supplied buffer. Adjust tools to match.
* VG_(apply_StackTrace): accept a void* argument, which is passed to
each invokation of the functional parameter (a poor man's closure
implementation).
* move PRINTF_CHECK into put_tool_basics.h, where it should have been
all along
* move private printf-into-an-XArray-of-character functions from
m_debuginfo into m_xarray, and make them public
* gen_suppression itself: use all the above changes. Basically we
always generate the plaintext version into an XArray. In text mode
that's just printed. In XML mode, we print the XMLery as before,
but the plaintext version is dumped into a CDATA block too.
* update the Protocol 4 specification to match all this.
This still isn't 100% right in the sense that the CDATA block data
needs to be split across multiple blocks if it should ever contain the
CDATA end mark "]]>". The Protocol 4 spec has this right even though
the implementation currently doesn't.
Fixes#191189.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10822
syscalls I've had the displeasure of encountering. Due to its
ridiculousness, the wrapper misses a PRE_MEM_WRITE check and so can result
in false positives. The POST_MEM_WRITE update is present, though, so it
shouldn't cause subsequent problems. Fixes bug 200760.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10786
* For all tools and the core, don't show statistics when -v is in
effect. Instead, try to restrict -v to mostly user-useful
stuff.
* A new flag --stats=no|yes [no] produces statistics output instead.
* Fix longstanding problem in that Memcheck's leak checker ran after
the core's error manager module shut down, thereby not showing use
counts of leak suppressions. This fixes#186790.
* As a consequence, the leak checker text output of Memcheck has
changed a bit -- leak check is done before the final error
summary is done (much more logical), and the output has been
tidied up a bit.
* Helgrind, Drd and Ptrcheck now also print "For counts of
detected and suppressed errors, rerun with: -v", which makes
them consistent with Memcheck in this regard. These are
filtered out by the regtest filter scripts.
For all tools except Memcheck, the regtests are unchanged. On
Memcheck regtests still fail due to rearrangements of the leak
checker output. This will be fixed by a followup commit.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10746
- Match the ordering of the non-tool-specific options in the usage message
with the order in the user manual. As a result, we now always print
--alignment and --trace-malloc in the core's usage messages, which saves
malloc-replacing tools from doing it themselves (and brings it in line
with options that only apply to error-collecting tools).
- Improved the presentation of the Vex options with --help-debug.
- Removed documentation of -d in the manual because it's a debugging-only flag.
- Documented --read-var-info in the manual. This fixes bug 201169.
- Renamed --auto-run-dsymutil as --dsymutil and documented it in the usage
message.
- Fixed an XML error in manual-core-adv.xml.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10703
VALGRIND_{PRINTF,PRINTF_BACKTRACE,INTERNAL_PRINTF} were no longer appending
newlines. This meant that --trace-malloc=yes spewed everything onto a
single line, among other things.
Rather than adding the newline back in, I chose to offically change their
behaviour to not add the newlines, as this is more flexible (and the reason
for the underlying VG_(message) change). I updated all the relevant places
I could find.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10694
* VG_(find_seginfo): incrementally rearrange the DebugInfo list, like
most of the other list-searching functions do.
* rename all VG_(*seginfo*) functions exported from m_debuginfo to
VG_(*DebugInfo*). "seginfo" was a historical name which was mostly
but not completely, done away with some time back.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10678
attempted to cross check against current kernel code. Reading the
futex system call code mostly just made my head hurt however...
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10656
reported in error messages were not correct. As an example, the following
output was produced before this patch (not correct):
$ ./vg-in-place --tool=helgrind --num-callers=1 /bin/true
...
FATAL: in suppressions file ".in_place/default.supp" near line 893:
suppression must contain at least one location line which is not "..."
exiting now.
$ ./vg-in-place --tool=drd --num-callers=1 /bin/true
FATAL: in suppressions file ".in_place/default.supp" near line 475:
suppression must contain at least one location line which is not "..."
exiting now.
After having applied this patch the above commands display line numbers
1104 and 619, referring to the first suppression pattern containing
three dots for the topmost stack frame, as expected.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10632
were longer than 200 chars. Now dynamic memory is used and so they can be
arbitrarily long in theory, although in practice it bombs out at 100,000 for
sanity purposes. This required adjusting the core/tool interface for
read_extra_suppression_info().
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10581
now has its own copy of custom_alloc.c which is a little different to
Memcheck's; making them both work with the same version was too difficult.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10455
This branch adds proper support for atomic instructions, proper in the
sense that the atomicity is preserved through the compilation
pipeline, and thus in the instrumented code.
These changes track the IR changes added by vex r1901. They primarily
update the instrumentation functions in all tools to handle the
changes, with the exception of exp-ptrcheck, which needs some further
work in order to be able to run threaded code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10392
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
- Put Darwin syscall DECL_TEMPLATEs in syscall order.
- Removed the "sys_" prefix from Darwin-specific wrappers, it's not
necessary. Renamed a couple of other wrappers similarly.
- Removed the sys_fcntl64 Darwin wrapper, it was unused.
- Improved some code layout.
Overall this removes 6 "DDD"/"GrP" fixme comments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10290
- Introduced VG_SYSNUM_STRING and VG_SYSNUM_STRING_EXTRA which factor out
differences in the way syscall numbers are printed on different platforms.
This gets rid of seven "DDD" fixme-style comments.
- This also meant that Darwin syscall numbers are now printed in a
non-ambiguous way -- previously Unix, machine-dependent and diagnostic
syscalls were all printed the same way, even though their numbers overlap.
Now each number is prefixed with "unix", "mdep", etc. And Mach trap
numbers aren't printed as negative numbers now that they have a "mach"
prefix.
- Split each of pub_core_vkiscnums.h and pub_tool_vkiscnums.h into two
parts, one suitable for inclusion in asm files, one suitable for inclusion
in C files; in both cases the latter includes the former. This makes
this module more like other modules that have asm-only components (eg.
m_transtab); it also allows the hacky VG_IN_ASSEMBLY_SOURCE macros and
tests to be removed.
- Removed some of the VG_DARWIN_SYSNO_* macros that were no longer needed,
and renamed some of the existing ones to make their meanings clearer.
- Added comments on the encoding of Darwin syscall numbers so it's
possible for mortals to understand without reading the kernel code..
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10218
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
