The number of errors for arguments that gets triggered depends
on how GCC optimzes and generates code for the vg_replace_malloc.c
wrappers. PPC seems to trigger more than amd64.
It returns NULL and 0 status whilst most other platforms
allocatae some undefined amount of memory (which is allowed
by posix).
Update the posix_memalign test as well.
Finally remove some clang warnings about alignment.
I had another look at the XNU source and this does seem to exist.
The manpage says that it is the zone version of posix_memalign,
though that's probably more because Darwin has no memalign.
This is the first part of
Bug 466104 aligned_alloc problems, part 1
The bulk of this change is try try to get memalign to be more
platform aware. Previously the Valgrind implementation only
reflected the glibc implementation. That meant non-power of
two alignment values would silently get bumped up to the
next largest power of two. Most other platforms return NULL
and set errno to EINVAL.
There are a few other changes. A couple of the other aligned alloc
functions like valloc were caling the Valgrind memalign. This meant
that there weould be an extra Valgrind memalign in any error
callstacks. Now these functions call the allocator directly.
The memcheck memalign2 testcase has been redone. The memalign
parts moved out to per-platform versions and the tescase
itdelf renamed to posix_memalign, since that is all that is left.
I also modified the testcase so that it checks that the
memalign calls check for non-NULL returns, and on platforms
that set errno that it is correctly set. Previously the
test only worked on non-glibc because NULL & alignment is
zero. The platform versions have been tested on glibc,
MUSL, FreeBSD and OpenIndiana and should hopefully run OK
both under memcheck and standalone.
There is stil quite a lot that is NOT done
1. I'm not certain that implementations allocate more memory
and/or use a wider alignment. It doesn't help that almost
universally the memalign implementations are badly
documented, undocumented or buggy.
2. We don't handle very large alignment requests well.
Most implementations will fail and set EINVAL if the
alignment is over half the memory space. Valgrind will
core panic if an aligmnt of over 16Mbytes is requested.
3. We don't generate any memcheck errors for invalid values
of alignment. That's planned in Part 2.
4. The code is static and fixed at compile time. That means that
if you are using MUSL with a glibc-built Valgrind you
will still get glibc memalign behaviour.
I'll wait to see if there are any requests before trying
to make the behaviour selectable at runtime.
rfork() is barely used in base FreeBSD. The main use
is in posix_spawn(). If rfork() fails with EINVAL
then it falls back to using vfork(). This is preferable
to Valgrind bombing.
ksh93 uses posix_spawn. I tested bash and csh and they had
no problems.
Also add 'hello world" smoke tests for bash csh and ksh
musl doesn't have sys/poll.h
GCC moans and then uses poll.h
On glibc linux and FreeBSD poll.h is a symlink to sys/poll.h
Illumos poll.h includes sys/poll.h
The hard coded memory mapping trigger drd_start_using_mem_w_perms
which will lead to tl_assert(vg_tid != VG_INVALID_THREADID);
But vg_tid was just set to VG_INVALID_THREADID before the
hard coded memory map.
GCC on RHEL 7.6 ARM complains about the empty init list.
I also noticed that we are using the SA_NOTIFY form of sigaction
(with that union member and handler prototype) but not setting the
SA_NOTIFY flag. Seems harmless in this case as we don't use
the siginfo or context.
cppcheck spotted a bug in the skipping of whitespace between shebang
and interpreter command. This could potentially cause the platform
to be misidentified (for x86 on amd64).
There was some code to handle /proc/curproc/file (a symlink to
the exe that wee need to bodge as it refers to the tool exe).
But it was neither tested nor working.
Can't use the same technique as Linux and Solaris which have more
complete /proc filesystems where each pid has symlinks for
each open file, which we use for the guest. Instead need to
copy the path ourselves. So move sys_readlink out of generic.
Simplify the handling of the resolved guest exe name - store it in
a global like VG_(args_the_exename).
bug464969_d_demangle depends on producing an error about an
uninitialized variable. But it prints something different
to stdout based on the value of that variable. Which can
produce failures. Make sure to always print the same thing
to stdout.
pth_mutex_signal.c:50:13: error: use of undeclared identifier 'SIGRTMAX'
sigaction(NATIVE_IO_INTERRUPT_SIGNAL, &signalAction, NULL);
Put this target under a condition for the moment.
AM_PROG_CC_C_O has been obsolete since automake 1.14.
AC_PROG_CC does the same check. With autoconf 2.70 we
must use AC_PROG_CC (which will check for c11 and c99),
for earlier versions we'll use AC_PROG_CC_C99.
