Add function checks to configure.ac
Use the configure HAVE_ macro rather than OS-dependent tests.
I suspect that a lot of the tests hve been obsolete for many
years. Add wrappers to FreeBSD.
:w
There is a difference between the outputs when using
32bit and 64bit with clang++/libc++
Running the test in a shell with the output piped through c++filt I see
64bit:
--2153-- operator new[](unsigned long)(32) = 0x55AB040
--2153-- malloc(31) = 0x55AB0A0
--2153-- operator new[](unsigned long)(8) = 0x55AB100
--2153-- operator new(unsigned long)(16) = 0x55AB150
--2153-- operator new(unsigned long)(16) = 0x55AB1A0
--2153-- operator new(unsigned long)(32) = 0x55AB1F0
--2153-- operator new(unsigned long)(32) = 0x55AB250
32bit:
--55024-- operator new[](unsigned int)(28) = 0x7D41030
--55024-- malloc(31) = 0x7D41090
--55024-- operator new[](unsigned int)(4) = 0x7D410F0
--55024-- operator new(unsigned int)(8) = 0x7D41140
--55024-- operator new(unsigned int)(8) = 0x7D41190
--55024-- operator new(unsigned int)(16) = 0x7D411E0
--55024-- operator new(unsigned int)(16) = 0x7D41230
--55024-- operator new(unsigned int)(32) = 0x7D41280
Note the extra 32 byte allocation at the end. This is because of
str2 += " rocks (str2)\n"; // interior ptr.
at the end of void doit(void)
Details of the mechaism here
https://stackoverflow.com/questions/21694302/what-are-the-mechanics-of-short-string-optimization-in-libc
str2 starts containing 9 characters "Valgrind"
Catenating to it makes it "Valgrind rocks (str2)\n" which is exactly 22 characters.
The 64bit SSO has a capacity of 22 chars, so there is no need to switch from
SSO in the stack variable to using heap allocation.
The 32bit SSO only has a capacity of 10, so there there is space
in the SSO for the initial string but the catenation expands it
beyond the SSO capacity and there is a heap allocation
via the std::basic_string allocator, which calls raw ::operator new.
These concern auxv, swapoff and fcntl F_KINFO
I wanted to use the new fcntl K_INFO to replace the existing
horrible implementation of resolve_filename, but it seems to
have change the behaviour for redirected files. Several
fdleak regtests fail because stdout resolves to an empty
string.
I've made these changes only for FreeBSD and Solaris for the moment.
I don't know what should be done on Linux for aligned_alloc/memalign.
The current Valgrind code refects the glibc implementation, but not
what the documentation says.
The difference is in the si_code. Linux has a value of 0, FreeBSD has
65537. This is correct.
From vki-freebsd.h
/*
* si_code values
*/
and indeed this signal gets sent by kill()
I'm not sure when this output changed.
This expected differs from the main GCC expected due to clang emitting
a cmovne for the ternary expression in 'use':
fprintf(stderr, "%d: Invalid value is %s\n", index, invalid ? "true" : "false");
Was getting warnings with clang like
memalign2.c:62:17: warning: requested alignment is not a power of 2 [-Wnon-power-of-two-alignment]
p = memalign(0, 100); assert(0 == (long)p % 8);
We haven't ran auxprogs/change-copyright-year since we switched to git.
This means most Copyright year ranges still say 2017. The script also
doesn't work for years >= 2020. Instead of trying to figure out how to
correctly update the per file Copyright year ranges just update the
main copyright notice that the program outputs on startup.
Currently, syscall memfd_create was tested by this:
$ perl tests/vg_regtest memcheck/tests/linux/memfd.vgtest
Since memfd_secret introduced in kernel 5.14, valgrind should rename
the "memfd" test to "memfd_create" test to avoid the ambiguity, so that
user will not get confused with the "memfd_secret" test.
After this change, syscall memfd_create will be tested by:
$ perl tests/vg_regtest memcheck/tests/linux/memfd_create.vgtest
For execve valgrind would silently fail when argv was NULL or
unadressable. Make sure that this produces a warning under memcheck.
The linux kernel accepts argv[0] being NULL, but most other kernels
don't since posix says it should be non-NULL and it causes argc to
be zero which is unexpected and might cause security issues.
This adjusts some testcases so they don't rely on execve succeeding
when argv is NULL and expect warnings about argv or argv[0] being
NULL or unaddressable.
https://bugs.kde.org/show_bug.cgi?id=450437
The syscall to realpathat was missing the buffer size argument.
By luck, no problem on amd64 but this failed on x86.
This adds the argument and a filter for the errors (size_t can be 4 or 8 bytes)
Adds syscall wrappers for __specialfd and __realpathat.
Also remove kernel dependency on COMPAT_FREEBSD10.
This change also reorganizes somewhat the scalar test
and adds configure time checks for the FreeBSD version,
allowing regression tests to be compiled depending on the
FreeBSD release.
From now on, scalar.c will contain syscalls for FreeBSD 11 and 12
and subsequent releases will get their own scalar, starting with
scalar_13_plus.c.
Also make drd/tests/shared_timed_mutex more robust
Already not great using time delays, but the test seems
to fail intermittently due to spurious wakeups. So instead
of railing straight away, make it "three strikes and you're out".
This patch rewrites the Level 2 origin-tracking cache (ocacheL2) so that
set-address-range-permissions (SARP) operations on it, for large ranges, are
at least a factor of 2.5 x faster. This is primarily targeted at SARPs in the
range of hundreds to thousands of megabytes. The Level 1 origin-tracking
cache covers 64MB address space, so SARPs that fit within it are mostly
unaffected. There are extensive comments in-line. Changes are:
* Change the Level 2 cache from a single AVL tree (OSet) into 4096 such trees,
selected by middle bits of the tag, hence "taking out" 12 significant bits
of search in any given tree.
* For the OCacheLine type, use a union so as to overlay the w32 and descr
arrays with an array of 64-bit values. This is used to speed up cases where
those fields are to be set to zero, or checked against zero.
* Due to the various fast-paths added by this patch, OC_BITS_PER_LINE has
pretty much been frozen at the current value, 5.
* ocache_sarp_Set_Origins, ocache_sarp_Clear_Origins: deal with large ranges
in 32-byte steps instead of 4-byte steps.
* MC_(helperc_b_store32), MC_(helperc_b_store16): rewrite these to be (much)
more efficient.
* fast-return cases for VG_(OSetGen_Lookup) and VG_(OSetGen_Remove) when the
tree is empty
* a few extra inline hints
There will be a lot more to come.
On amd64 Linux
In faultstatus was seeing the division by zero and emitting a ud2 opcode.
In wrap3 a pair of mutually recursive functions were being inlined.
When forced not to be inlined GCC merged them into a single function.
It cannot see that the client requests have diffeent behaviour.
The name malloc-leaks-cxx-stl-string-classes-debug was confusing
since the suppression wasn't a leak, not part of stl, string,
classes or debug. Rename it to libstdcxx-emergency-eh-alloc-pool
to indicate it is part of the emergency exception handling memory
pool.
Note that suppression is only needed for some test cases, normally
the pool is cleaned up as part of cxx_freeres.
This time with debuginfo removed.
Also update the vgtest files for a couple of massif tests
(and also the expected because of the commmand line change).
Not yet tested these two with debuginfo installed.
