declining rates, so as to reduce the amount of junk spewed out by
the various support functions for the MacOS syscall wrappers.
* add a couple more cases to the resync filter for Yosemite. This
is working pretty well now.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14725
Two things:
- remove the buffer argument from VG_(DebugInfo_sect_kind)
- allocate AddrInfo::SectKind::objname dynamically
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14719
* 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
In the non-XML part buf_dirname was read without observing the
know_dirinfo guard. Now fixed. Initialise buf_dirname nevertheless.
Also remove a dead assignment.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14707
(a) the 2nd argument must not be NULL
This was true anyhow and requiring it allows us to simplify the function
by eliminating the local buffer.
(b) the memory pointed to by the 2nd argument is always initialised
In the past the output file name was not initialised in case VG_(open)
failed 10 times in a row. The call sites in m_main.c and m_gdbserver/target.c
were reading the uninitialised filename unconditionally. This was spotted
by IBM's BEAM checker.
Fix call sites, eliminate some magic constants along the way.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14706
* Clarify in the dedup pool comments that all bytes of elements are compared.
* pub_core_options.h : remove old/misplaced comment for clo_trace_children
and replace by a more clear comment (matching the --help)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14704
Basically:
CLG_(sprint_eventmapping) --> CLG_(eventmapping_as_string)
CLG_(sprint_mappingcost) --> CLG_(mappingcost_as_string)
The new functions return the string in a dynamically allocated buffer
that caller ought to free.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14699
syscall numbers, and dummy wrappers for bsdthread_ctl and
sysctlbyname. Mash up of patches from fxcoudert@gcc.gnu.org and Rhys
Kidd (rhyskidd@gmail.com). Part of bug 339045.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14698
of __PAGEZERO to zero. Without this, the 10.10 kernel refuses to
start these executables. Based on investigations and a
proof-of-concept implementation by Rhys Kidd (rhyskidd@gmail.com).
Part of bug 339045.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14697
Not sure why this is necessary, but without it, the tool executables
don't link. Part of bug 339045.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14696
(/system/bin/ls, /system/bin/date) run. Still to do:
* enable more malloc/free intercepts
* enable wrappers for ashmem and binder syscalls
* check to see if any special ioctl support is required for ARM Mali GPUs
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14690
only to check the lowest 32 bits, since that arg is a file descriptor
-- hence "int" -- and checking all 64 bits fails unexpectedly if ARG1
and VKI_AT_FDCWD are not both zero- or sign- extended.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14689
Prepare print_file function to be converted to use VG_(fprintf).
Basically get rid of arithmetic involving the output buffer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14687
Changes VG_(describe_IP) to return the untruncated result in a statically
allocated local buffer. Fix call sites and update two .exp files who had
truncated names.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14685
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
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
mknodat (33), fchdir (50), chroot (51), fchownat (54)
Patch from Miroslav Franc (mfranc@redhat.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14677
