made from file-backed mappings (AOT code, basically) that is different
from the default behaviour as specified by --vex-iropt-register-updates.
New flag is --px-file-backed=, with the same possible args as
--vex-iropt-register-updates has.
Add a new flag --px-default, which is a short alias for
--vex-iropt-register-updates.
Add one line of stats output when --stats=yes, showing counts of how
many translations have been made under each of the 4 different PX
optimisation settings.
No user-visible change if you don't use the new flags.
Relies on VEX API change in r3084.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14906
the dirname_available parameter. It's redundant. The value
of the returned directory name can be tested instead.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14814
VG_(debugLog_vprintf).
Remove function VG_(percentify) and fix up its call sites (part of
fixing BZ #337869.
Allow the width in a format specification to be '*', i.e. the width is
given as an additional function argument.
The limitations for printing floating point numbers are:
(1) %f is the only supported format. Width and precision can be
specified.
(2) Funny numbers (NaN and such) are not supported.
(3) Floating point numbers need to be benign in the sense that their
integral part fits into an ULong.
This is good enough for our purposes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14806
Assorted fixes in exp-bbv to eliminate a few buffers.
Implement a suggestion found in the massif source, namely to add the
equivalent of fprintf to m_libcprint. Good suggestion. Thusly
- VgFile: similar to FILE; buffered output, 8k buffer
- VG_(fopen): similar to fopen, but with arguments as in VG_(open)
- VG_(fprintf) and VG_(vfprintf): like [v]fprintf with VgFile 1at argument
- VG_(fclose)
Change massif, exp-bbv and cachegrind to use this functionality.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14678
the array element for NULL. Function VG_(split_up_argv), which
sets up that array, ensures that no element is NULL.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14671
The functions VG_(get_filename) and VG_(get_filename_lineno) now return
a pointer to filename and directory name instead of copying them into
buffers passed in from the caller.
The returned strings are persistent as long as the DebugInfo to which
they belong is not discarded. The caller therefore needs to stash them
away as needed.
Function VG_(strncpy_safely) has been removed as it is no longer needed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14668
What it does it changing cachegrind's get_debug_info function such
that it no longer builds up an absolute pathname. Instead the function
get an additional parameter for the directory name and the absolute
pathname is built when it is needed. This will come in handy soonish
when VG_(get_filename_lineno) will be changed and those buffers will
disappear.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14665
This patch changes the interface and behaviour of VG_(demangle) and
VG_(maybe_Z_demangle). Instead of copying the demangled name into a
fixed sized buffer that is passed in from the caller (HChar *buf, Int n_buf),
the demangling functions will now return a pointer to the full-length
demangled name (HChar **result). It is the caller's responsiblilty to
make a copy if needed.
This change in function parameters ripples upward
- first: to get_sym_name
- then to the convenience wrappers
- VG_(get_fnname)
- VG_(get_fnname_w_offset)
- VG_(get_fnname_if_entry)
- VG_(get_fnname_raw)
- VG_(get_fnname_no_cxx_demangle)
- VG_(get_datasym_and_offset)
The changes in foComplete then forces the arguments of
- VG_(get_objname) to be changed as well
There are some issues regarding the ownership and persistence of
character strings to consider.
In general, the returned character string is owned by "somebody else"
which means the caller must not free it. Also, the caller must not
modify the returned string as it possibly points to read only memory.
Additionally, the returned string is not necessarily persistent. Here are
the scenarios:
- the returned string is a demangled function name in which case the
memory holding the string will be freed when the demangler is called again.
- the returned string hangs off of a DebugInfo structure in which case
it will be freed when the DebugInfo is discarded
- the returned string hangs off of a segment in the address space manager
in which case it may be overwritten when the segment is merged with
another segment
So the rule of thunb here is: if in doubt strdup the string.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14664
r14271 Audit a few buffer sizes, increase one.
r14280 Audit buffer size.
r14296 Remove a few unneeded header files.
r14310 Replace fixed size buffers with a large enough buffers.
r14338 Remove a dead assignment in print_bbcs and make global variable
print_fd a local variable.
r14359 Remove a benign macro redefinition in cachegrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14595
possibly be NULL in several places. Nowadays, VG_(ii_create_image) will
terminate the process if VG_(args_the_exename) is NULL.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14323
Callgrind, Cachegrind, and Lackey call
helpers for memory accesses in bunches, to reduce
register save/restore overhead (and merge load/store
within same instruction into a "modify" event).
The calls should not be done within a RMW section
enclosed by LL/SC instructions, as this reduces the
chance of SC to succeed, and can result in hangs.
For Callgrind, this definitly helped MIPS, and was
committed in r13136. Do the same for Cachegrind/Lackey.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13143
Because most Ir accesses touch only one line, and this
can be detected at instrumentation time, use a special
handler for that. This handler does not need to check
cache line crossing at runtime.
This does not change the results of the simulator at all,
but improves runtime by around 15% on perf benchmarks.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13095
Makes modifications simpler in the future, and
should result in the same code.
This patch was already discussed some time ago on the
dev mailing list, and did not make a difference on
various architectures.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13024
Option sp-at-mem-access can be used by tools which do not
need an up to date BP and IP at each mem access.
It is needed however to have SP up to date at each memory
access, as an up to date SP is needed to grow the stack in
m_signals.c
Tools massif, cachegrind and callgrind are using sp-at-mem-access
as default.
None tool could also use sp-at-mem-access but default is kept
to unwindregs-at-mem-access (similar to memcheck, drd, helgrind, exp-sgcheck).
exp-dhat, exp-bbv, lackey have not been looked at to see if they
could make use of sp-at-mem-access.
Validated on x86, amd64, ppc64 and s390x.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12872
cachegrind: use the new function to abort startup if the minumum line
size is smaller than the size of the largest guest register.
Partially derived from a patch by Josef Weidendorfer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12605
Patch by Philippe Waroquiers, slightly changed.
This actually was a regression from 3.6.1, but the patch
also improves on printed messages, and refactors common
code between cachegrind and callgrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12013
of the L2 cache. This is to accommodate machines with three levels of
cache. We still only simulate two levels, the first and the last.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11404
* do indirect branch prediction simulation on calls
via function pointers
* only call into conditional branch prediction simulation
on real guest code branches (eg. not for VEX emulation of some
instructions using branches of jumpkind Ijk_EmWarn)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11331
messages now begin with "valgrind: ", and they're more often printed before
the preamble. This required introducing a new message kind, Vg_FailMsg, and
functions VG_(fmsg) and VG_(fmsg_bad_option), and removing
VG_(err_bad_option).
Where we used to have horrible output like this:
[ocean:~/grind/ws2] vg5 --tool=massif --threshold=101 date
==31877== Massif, a heap profiler
==31877== Copyright (C) 2003-2010, and GNU GPL'd, by Nicholas Nethercote
==31877== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
==31877== Command: date
==31877==
==31877== --threshold must be between 0.0 and 100.0
valgrind: Bad option '--threshold'; aborting.
valgrind: Use --help for more information.
We now have nice output like this:
[ocean:~/grind/ws2] vg2 --tool=massif --threshold=101 date
valgrind: Bad option: --threshold=101
valgrind: --threshold must be between 0.0 and 100.0
valgrind: Use --help for more information or consult the user manual.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11209
* 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
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
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
DARWIN branch. A big ugly DARWIN/trunk sync commit, mostly to do with
changing the representation of SysRes and vki_sigset_t. Functionality of
the trunk shouldn't be changed by it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9876
