segment if it is past the heap end
Describes specifically an address that is in the brk data segment
or in the 'reduced' (after brk reduction) section of the brk data segment.
Based on a patch from Ivo Raisr.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14833
VG_PLAT_USES_PPCTOC is only true for PPC64 big endian, do not
need to quailify the #if statement condition of VG_PLAT_USES_PPCTOC
with !VGP_ppc64le_linux.
There is no associated bugzilla. The fix is in response to an
email message.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14822
arm64, like amd64, must not use VKI_IPC_64, even
if this symbol is defined.
This makes the shmctl fail, which results in a zero size returned,
which means that the succesful shmat is not reported to the aspacemgr.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14821
(valgrind side).
In summary: we were counting somewhat on the luck for FS,
we now similarly count on luch for GS
See VEX commit log r3043 for more details.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14815
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
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
had no pthread barrier.
(the Makefile.am protects this with a if HAVE_PTHREAD_BARRIER)
But the test should then be protected with a prereq that the
executable exists.
(analysis and fix suggestion by rhyskidd, part of fixing 341613)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14807
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
Set VEX_HWCAPS_X86_SSE3 accordingly.
This came about by grepping the source for VEX_HWCAPS_X86_SSE3
and observing that the flag was tested for (in VEX) but not set.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14803
Use proper initialisation functions for the type and variable parser.
Add functions to release the dynamically allocated functions.
No longer maintain content of popped-off stack entries as that is
essentially freed memory and complicates matters unnecessarily.
Part of fixing BZ #337869.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14801
This was not as straight forward as expected. Specifically, adding the
new flag to CFLAGS in configure.ac did not work and was causing
compiler warnings. For instance, compiling memcheck/tests/execve2.c will
generate a -Wnonnull warning even though the testcase is explicitly
compiled with -Wno-nonnull. The reason is that (a) -Wformat is implied by
-Wnonnull and (b) the list of compiler flags gets assembled in the wrong
order. The culprit appears to be that we modify CFLAGS in configure.ac and
that really is not the right place. Conceptually, configure should determine
tool-chain capabilities and not assemble compiler flags. That should be done
in Makefiles. This patch entangles all this.
So, whatever was added to CFLAGS in configure.ac has now been moved to
Makefile.all.am and Makefile.tool-tests.am. Those are:
-Wno-long-long
-Wwrite-strings
-Wcast-qual
-fno-stack-protector
Note, that this change allows us to simplify Makefile.tool-tests.am which
in the past was disabling some of those flags (e.g. by adding -Wno-cast-qual
again).
In case of the clang compiler, extra command line options are needed. I've
moved those into a separate 'if COMPILER_IS_CLANG' section and not merge
them into baseline flags.
Related to BZ 334727.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14798
--log-file= on the command line results in the following error:
valgrind: --log-file: filename is emptyBad option: --log-file=
...
Relatedly, fix the 1st argument to VG_(expand_file_name) in coredump-elf.c.
This should not contain additional verbiage as it is assumed to be an option
name which us used to construct an error message containing
option_name=file_name
As an aside, this logic in coredump-elf.c seems odd:
If VG_(clo_log_fname_expanded) is not NULL, then it has already been
expanded in main_process_cmd_line_options. Expanding it again would only
make a difference, if the original logfile name contained an environment
variable whose value contained %q{whatever} thereby referring to a yet
another environment variable. That seems strange.
But I'm not touching it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14794
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
