This is a change probably related to clang 13.
guard variables make the initialization of function static variables
thread safe (only the initialization, not other accesses).
I should perhaps just delete these expected. The testcases don't
work well with the stripped libstc++ without debuginfo on FreeBSD.
That means that the --ignore-fn= options don't work to remove
exception handling and iostream allocations and just leave the
tesatcase allocations.
After working on an issue that turns out to seem to be with the
FreeBSD kernel sched_uler I played a lot with the Valgrind
syscall and scheduler code. I've kept the comments and the
reformatting.
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.
On FreeBSD 13.0 x86 this testcase was hanging on some systems.
It seems like the SIGTERM signals were not being recieved
before the child exited, which left the parent hanging in the
pause() waiting to be killed.
Reported, patch provided and tested by Nick Briggs.
Currently debuginfod is enabled in Valgrind when the $DEBUGINFOD_URLS
environment variable is set and disabled when it isn't set.
This patch adds an --enable-debuginfod=<yes|no> command line option
to provide another level of control over whether Valgrind attempts
to download debuginfo. "yes" is the default value.
$DEBUGINFOD_URLS must still contain debuginfod server URLs in order
for this feature to work when --enable-debuginfod=yes.
https://bugs.kde.org/show_bug.cgi?id=453602
With clang 13 none/tests/amd64/amd64locked fails because of what
looks like a clang optimization error. do_bt_G_E_tests is the
point of failure, and one factor is that clang 13 is inlining
myrandom().
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.
In glibc 5aad5f617892e75d91d4c8fb7594ff35b610c042 (first released in
v2.28) a call to strncmp was added to dl-load.c:is_dst. This causes
valgrind to complain about glibc's highly-optimised strncmp performing
sixteen-byte reads on short strings in ld.so. Let's intercept strncmp in
ld.so too so we use valgrind's simple version to avoid this problem.
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);
memfd_secret is a new syscall in linux 5.14. memfd_secret() is
disabled by default and a command-line option needs to be added to
enable it at boot time.
$ cat /proc/cmdline
[...] secretmem.enable=y
https://bugs.kde.org/451878https://lwn.net/Articles/865256/
It fixes a known iusse whose details are described at [1] and more
generally it guarantees that Valgrind is properly compiled for ulibc.
[1] https://www.mail-archive.com/valgrind-users@lists.sourceforge.net/msg05295.html
Suggested-by Michael Trimarchi <michael@amarulasolutions.com>
Co-developed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
