This allows to decrease memory usage when using many threads,
if no big stacksize is needed by Valgrind.
If needed (e.g. for demangling big c++ symbols), the V stacksize
can be increased.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15004
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
Left justification of strings in myvprintf_str was mixed up.
Now fixed and %s formats changed accordingly.
In function myvprintf_int64: the local buffer was not large
enough to hold ULONG_MAX in binary notation. Numbers were
truncated at 39 digits.
Testcases added.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14808
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
This is a follow up to VEX r3028. This change adds two test cases
for Cavium instructions BBIT032 and BBIT132.
Issue tracked in BZ #339288.
Patch by Maran Pakkirisamy.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14792
* This option can be used to mark the begin/end of errors in textual
output mode, to facilitate searching/extracting errors in output files
mixing valgrind errors with program output.
* Use the new option in various existing regtests to test the various
possible usage.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14714
Bug is not really fixed, instead the SHM_HUGETLB flag is ignored.
Note that it is not straightforward to properly fix this,
as this implies either to learn aspacemgr what huge pages are.
Also, the trick used in the fix for 333051 cannot be used easily,
because the SHM_HUGETLB flag is given in shmget, while the mmap
is done in shmat.
So, the easiest is to just ignore the SHM_HUGETLB flag.
SHM_HUGETLB is supposed to only give a performance impact.
Ignoring it should be benign.
Theoretically, the caller might expect a sucessful shmget(SHM_HUGETLB)+shmat
to give pages aligned on e.g. 1MB.
In this case, bad luck, the program will misbehave under valgrind.
To warn of this, a warning is given (once) when SHM_HUGETLB is seen.
The map_unmap.c test has been restructured somewaht to allow
TEST_SHM_HUGETLB to be tested independently (or not) of the TEST_MAP_HUGETLB.
Note also that by default, testing MAP_HUGETLB and SHM_HUGETLB
is disabled as usually, huge pages are not enabled.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14683
Learning aspacemgr to handle huge page is too difficult.
So, huge page requests that fails due to bad advice by aspacemgr
will (we hope) succeed if a mmap retry is done with the kernel,
without any constraints.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14682
that they are called, so as to make future editing easier. And
generally tidy up. No functional change.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14681
FMLA 2d_2d_d[], 4s_4s_s[], 2s_2s_s[]
FMLS 2d_2d_d[], 4s_4s_s[], 2s_2s_s[]
PRFM (immediate)
Unfortunately huge diff for arm64/fp_and_simd.stdout.exp because the
new cases are not at the end, and the random data for all after it is
different. ToDo: reset RNG after each test.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14679
Cavium toolchain defaults to soft-float, so it is important to enable full
build of the test suite to work in that case as well.
This boils down to protecting FPU-specific code segments with
#if defined(__mips_hard_float)
#endif
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14572
Check whether the target platform is meant to have an FPU before executing
tests that make use of a floating-point unit.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14571
