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.
The problem is that the testcase specific suppression has stacks
that are too specific. This causes breakage with different versions
of GCC and libstdc++. The suppression only needs to mask the memory
pool used for standard io.
There are several suppression stanzas so future tweaks may still be
necessary.
Clang uses CMOV for ternary operators which does not immediately
trigger an error. Using double free and new/free mismatch still
poses no problem with clang but still uses the demangling.
Also update .gitignore
This is unfortunately a big and complex patch, to implement LD{,A}XP and
ST{,L}XP. These were omitted from the original AArch64 v8.0 implementation
for unknown reasons.
(Background) the patch is made significantly more complex because for AArch64
we actually have two implementations of the underlying
Load-Linked/Store-Conditional (LL/SC) machinery: a "primary" implementation,
which translates LL/SC more or less directly into IR and re-emits them at the
back end, and a "fallback" implementation that implements LL/SC "manually", by
taking advantage of the fact that V serialises thread execution, so we can
"implement" LL/SC by simulating a reservation using fields LLSC_* in the guest
state, and invalidating the reservation at every thread switch.
(Background) the fallback scheme is needed because the primary scheme is in
violation of the ARMv8 semantics in that it can (easily) introduce extra
memory references between the LL and SC, hence on some hardware causing the
reservation to always fail and so the simulated program to wind up looping
forever.
For these instructions, big picture:
* for the primary implementation, we take advantage of the fact that
IRStmt_LLSC allows I128 bit transactions to be represented. Hence we bundle
up the two 64-bit data elements into an I128 (or vice versa) and present a
single I128-typed IRStmt_LLSC in the IR. In the backend, those are
re-emitted as LDXP/STXP respectively. For LL/SC on 32-bit register pairs,
that bundling produces a single 64-bit item, and so the existing LL/SC
backend machinery handles it. The effect is that a doubleword 32-bit LL/SC
in the front end translates into a single 64-bit LL/SC in the back end.
Overall, though, the implementation is straightforward.
* for the fallback implementation, it is necessary to extend the guest state
field `guest_LLSC_DATA` to represent a 128-bit transaction, by splitting it
into _DATA_LO64 and DATA_HI64. Then, the implementation is an exact
analogue of the fallback implementation for single-word LL/SC. It takes
advantage of the fact that the backend already supports 128-bit CAS, as
fixed in bug 445354. As with the primary implementation, doubleword 32-bit
LL/SC is bundled into a single 64-bit transaction.
Detailed changes:
* new arm64 guest state fields LLSC_DATA_LO64/LLSC_DATA_LO64 to replace
guest_LLSC_DATA
* (ridealong fix) arm64 front end: a fix to a minor and harmless decoding bug
for the single-word LDX/STX case.
* arm64 front end: IR generation for LD{,A}XP/ST{,L}XP: tedious and
longwinded, but per comments above, an exact(ish) analogue of the singleword
case
* arm64 backend: new insns ARM64Instr_LdrEXP / ARM64Instr_StrEXP to wrap up 2
x 64 exclusive loads/stores. Per comments above, there's no need to handle
the 2 x 32 case.
* arm64 isel: translate I128-typed IRStmt_LLSC into the above two insns
* arm64 isel: some auxiliary bits and pieces needed to handle I128 values;
this is standard doubleword isel stuff
* arm64 isel: (ridealong fix): Ist_CAS: check for endianness of the CAS!
* arm64 isel: (ridealong) a couple of formatting fixes
* IR infrastructure: add support for I128 constants, done the same as V128
constants
* memcheck: handle shadow loads and stores for I128 values
* testcase: memcheck/tests/atomic_incs.c: on arm64, also test 128-bit atomic
addition, to check we really have atomicity right
* testcase: new test none/tests/arm64/ldxp_stxp.c, tests operation but not
atomicity. (Smoke test).
The demangle-rust.vgtest would fail because the demangle-rust binary
wasn't build by default. Add it to check_PROGRAMS and define
demangle_rust_SOURCES to make sure it is always build.
It's currently broken due to a silly test that prevents the v0
demangling code from even running.
The commit also adds a test, to avoid such problems in the future.
Because of what looks like some copy/paste issues the new F16 Iops
seem to be tested on the wrong architectures. They are only implemented
on arm64. So this patch only enables them for arm64.
https://bugs.kde.org/show_bug.cgi?id=444831
With glibc 2.34 we would start seeing some function names ending in
'@*' this was already filtered out using drd/tests/filter_stderr.in
but not when using the drd xml tests. This would make
drd/tests/thread_name_xml and drd/tests/bar_bad_xml fail.
Filter this out in the memcheck/tests/filter_xml script, which is
also used by the drd test filters.
Tested against glibc 2.34, 2.33 and 2.17 on x86_64.
There's one remaining
memalign2.c:29:9: warning: unused variable 'piece' [-Wunused-variable]
because of a block of #if FreeBSD for memalign that looks unnecessary
Otherwise all that is left is a few like
warning: unknown warning option '-Wno-alloc-size-larger-than'; did you mean '-Wno-frame-larger-than='? [-Wunknown-warning-option]
because there is no standard for compiler arguments.
GCC12 catches various issues in tests at compile time that we want to
catch at runtime. Also glibc 2.34 deprecated various mallinfo related
functions. Add the relevant -Wno-foobar flags to those tests. In one
case, unit_oset.c, the warning was correct and the uninitialized
variable was explicitly set.
Various tests do things which we want to detect at runtime, like
ignoring the result of malloc or doing a deliberate impossibly large
allocation or operations that would result in overflowing or
truncated strings, that generate a warning from gcc.
In once case, mq_setattr called with new and old attrs overlapping,
this was explicitly fixed, in others -Wno-foobar was added to silence
the warning. This is safe even for older gcc, since a compiler will
ignore any -Wno-foobar they don't know about - since they do know they
won't warn for foobar.
Files in the root directory
Several Makefile.am files that have dependencies on FreeBSD autoconf
variables. Included a few new filter files to act as placeholders
to create new freebsd subdirectories.
Updated NEWS with the FreeBSD bugzilla items plus a couple of other
items fixed indirectly.
Update the libiberty demangler using the auxprogs/update-demangler
script to the gcc git 01d92cfd79872e4cffc78bf233bb9b767336beb8.
Updates rust demangling to support the new v0 mangling scheme.
This includes the following changes:
- Update the update-demangler script to use gcc git instead of svn.
- The result of running the updated script to get an updated
demangler and resolving the merge conflicts.
- A change to long_namespace_xml.stderr.exp because two overly long
symbols aren't demangled anymore, but just returned as is.
- an update to the m_demangle/demangle.c source to deal with Rust
demangling in cp_demangle, which now directly demangles old and
new style rust symbols.
Add test cases for verifying the new/enhanced instructions in the
vector-enhancements facility 2. For "vector string search" VSTRS add a
memcheck test case.
Bug 434296 addresses memcheck false positives with the vector string
instructions VISTR, VSTRC, VFAE, VFEE, and VFENE. Add test cases that
verify the fix for that bug. Without the fix, memcheck yields many
complains with these tests, most of which are false positives.
The fix for bug 429864 - "s390x: C++ atomic test_and_set yields
false-positive memcheck diagnostics" changes the memcheck behavior at
various compare-and-swap instructions. The comparison between the old and
expected value now always yields a defined result, even if the input
values are (partially) undefined. However, some existing test cases
explicitly verify that memcheck complains about the use of uninitialised
values here. These test cases are no longer valid. Remove them.
Explicitly use ordinary scalar delete and update the expecteds.
Otherwise g++ uses sized scalar delete whilse clang uses
ordinary scalar delete which causes a diff.
The VG_(get_fnname_kind) function detects some special "below main"
function names. Specifically __libc_start_main and generic_start_main
both of which are used to call the actual main () function from the
application. We already recognized one variant, generic_start_main.isra.0,
but only for powerpc. Recognize all possibly specialed optimized variants
gcc can produce by simply checking for the function name with dot as
prefix. This fixes the memcheck/tests/supp_unknown.vgtest and
massif/tests/deep-D.vgtest with gcc 11.
We can now also get rid of the special cases in
massif/tests/deep-D.post.exp-ppc64 and memcheck/tests/supp_unknown.supp.
https://bugs.kde.org/show_bug.cgi?id=430158
debuginfod is an HTTP server for distributing ELF/DWARF debugging
information. When a debuginfo file cannot be found locally, Valgrind
is able to query debuginfod servers for the file using its build-id.
readelf.c: Add debuginfod_find_debug_file(). Spawns a child process to
exec `debuginfod-find` in order to query servers for the debuginfo
file. Also add helper debuginfod_find_path().
pub_core_pathscan.h: Moved from priv_initimg_pathscan.h in order to use
VG_(find_executable)() in readelf.c.
docs: Add information regarding debuginfod to valgrind.1
memcheck/tests/linux: Add new test debuginfod-check.
tests/vg_regtest.in: Clear $DEBUGINFOD_URLS before running any tests.
https://bugs.kde.org/show_bug.cgi?id=432215
When one of the allocation functions in vg_replace_malloc failed
they return NULL, but didn't set errno. This is slightly tricky since
errno is implementation defined and might be a macro. In the case of
glibc ernno is defined as:
extern int *__errno_location (void) __THROW __attribute__ ((__const__));
#define errno (*__errno_location ())
We can use the same trick as we use for __libc_freeres in
coregrind/vg_preloaded.c. Define the function as "weak". This means
it will only be defined if another library (glibc in this case)
actually provides a definition. Otherwise it will be NULL.
So we will only call it if it is defined and one of the allocation
functions failed, returned NULL.
Include a new linux only memcheck testcase, enomem.vgtest.
https://bugs.kde.org/show_bug.cgi?id=217695
On Fedora 33 with gcc (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9)
it looks like fun:__static_initialization_and_destruction_0 is
now inlined which causes the existing suppression for the
same reachable to no longer match.
