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
VG_(newSizedXA)) since r11571 removes the only use of the
functionality that r11568 introduces.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11573
identical to VG_(newXA) but allows passing in a size hint. In the
case where the likely final size of the XArray is known at creation
time, this allows avoiding the repeated (implicit) resizing and
copying of the array as elements are added, which can save a vast
amount of dynamic memory allocation turnover.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11568
workload: when scanning a freelist of a given size for a big-enough
block (to allocate), don't scan all the way around the list. Instead
give up after 100 blocks and try the freelist above. The pathological
case (as observed) is that the freelist contains tens of thousands of
blocks, but all are too small for the current request, hence they are
all visited pointlessly. If the new heuristic is used, the freelist
start point is moved along by one block, so that future searches
eventually inspect the entire freelist, just very slowly.
Also, some improvements to stats gathering, and rename of some
existing stats fields in struct Arena.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11567
Also, improve the failure message a bit, so as to tell people what package
they need to install, in at least some cases.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11538
Useful if the program in question catches signals, in which case the usual
"Process terminating..." stack trace isn't shown. Requested by Jesse
Ruderman.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11504
(1) allowing translations to chase across BB boundaries, as in the
non-smc-check case
(2) on 64-bit targets, do the checksumming with 64-bit loads
instead of 32-bit ones.
(valgrind-side change, to match vex r2070)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11495
Massif: specify avg translation size at all, so as to avoid excessive
retranslations caused by the fact that the default value is far below
reality for Massif.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11494
is how mmap() sizes are treated. It fixes an assertion failure in Massif
with --pages-as-heap=yes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11485
chase/nochase decisions for child processes to be made on the basis
of their argv[] entries rather than on the name of their executables.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11483
* better progress messages, to make it clear that reading of a
PDB is finished, and how much stuff was read from it
* don't mmap PDB files to read them -- instead use VG_(read).
This is because CIFS filesystem mounting only works reliably on
Linux when mounted with option '-o directio', and that
disallows mmap-ing files.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11482
behave more like the original proposal in #245535. This makes it
more flexible and general. Also rename it.
* new name is --fullpath-after=
* allow multiple instances of --fullpath-after=
* don't require the specified strings to be prefixes, only substrings
But retain the elegant backwards-compatibility trick in Bart's r11312
commit: if --fullpath-after= is not specified at all, then behave
exactly as before.
Fixes#245535. A mixture of patches from Bart Van Assche
(bart.vanassche@gmail.com), Alexander Potapenko (glider@google.com),
and me (integration and documentation).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11430
- "*(int *)0 = " is apparently ignored by LLVM for who-knows-why
reason. Cast the zero to a volatile int * instead.
- remove an unused function that gcc failed to mention was unused
(why? because it was marked __attribute__((noreturn)) ?)
As an aside, clang/llvm-2.8 seemed to be able to successfully
compile Valgrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11429
unbreaks the build breakage on Darwin introduced in r11397, which
was a fix for #234064. The breakage was subsequently reported
in #253420 and #253452, which this commit fixes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11406
bogus, and produces essentially useless traces from them. With
gcc-4.4 and later, some valid thread stacks really are smaller than
this. Hence change the limit down to 256 bytes. Investigated by
Evgeniy Stepanov, eugeni.stepanov@gmail.com.
See bug 243270 comment 21.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11403
account rounding requirements to SHMLBA. Modified version of a patch
by Kirill Batuzov, batuzovk@ispras.ru. This fixes the main bug in
#222545. Temporarily breaks the build on all other platforms though.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11399
except on amd64-linux. This fixes a secondary problem discussed
in bug 222545. (Kirill Batuzov, batuzovk@ispras.ru)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11398
read debuginfo from, use VKI_O_LARGEFILE, so as to ensure the open
succeeds for large files on 32-bit systems. Fixes#234064.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11397
for the old segment so we need to save the permissions from it before
the call so that we can use them when notifying tools of the new space
afterwards, or we will notify them of the wrong permissions.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11384
knows how to unwind. This is important when unwinding Thumb code
the CFA is often stated as being at some offset from r7.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11377
code_alignment_factor, thereby assuming it is 1. This happens to be
OK on amd64-linux and s390x-linux because it really is 1, but on
arm-linux it is 2, and hence the boundaries between code-unwind areas
are simply wrong after any of DW_CFA_advance_loc{,1,2,4} are
processed. This patch provides the obvious fix.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11376
ptrace into the child, so as to be a legitimate instruction
address in both ARM and Thumb mode.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11375
AUXV at startup, rather than by trying to execute a Neon instruction
and seeing whether it SIGILLs. Apparently the latter is not a
reliable way to ascertain the presence of usable Neon support. Fixes
#249775.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11347
stack-overflow situations. This causes an immense number of L2 misses
which are completely pointless, and the recent increase of the
Valgrind per-thread stack size from 64k to 1M greatly aggravates the
situation.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11343
time to find out how much space DCBZL really clears, and make the
guest CPU act accordingly. (valgrind-side changes).
(Dave Goodell, goodell@mcs.anl.gov)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11337
