Contributed by Will Schmidt <will_schmidt@vnet.ibm.com>
This includes updates and adjustments as suggested by Carl.
Add tests that exercise PCRelative instructions.
These instructions are encoded with R==1, which indicate that
the memory accessed by the instruction is at a location
relative to the currently executing instruction.
These tests are built using -Wl,-text and -Wl,-bss
options to ensure the location of the target array is at a
location with a specific offset from the currently
executing instruction.
The write instructions are aimed at a large buffer in
the bss section; which is checked for updates at the
completion of each test.
In order to ensure consistent output across assorted
systems, the tests have been padded with ori, nop instructions
and align directives.
Detailed changes:
* Makefile.am: Add test_isa_3_1_R1_RT and test_isa_3_1_R1_XT tests.
* isa_3_1_helpers.h: Add identify_instruction_by_func_name() helper function
to indicate if the test is for R==1.
Add helpers to initialize and print changes to the pcrelative_write_target
array.
Add #define to help pad code with a series of eyecatcher ORI instructions.
* test_isa_3_1_R1_RT.c: New test.
* test_isa_3_1_R1_XT.c: New test.
* test_isa_3_1_R1_XT.stdout.exp: New expected output.
* test_isa_3_1_R1_XT.stdout.exp: New expected output.
* test_isa_3_1_R1_RT.stderr.exp: New expected output.
* test_isa_3_1_R1_RT.stderr.exp: New expected output.
* test_isa_3_1_R1_RT.vgtest: New test handler.
* test_isa_3_1_R1_XT.vgtest: New test handler.
* test_isa_3_1_common.c: Add indicators (updates_byte,updates_halfword,
updates_word) indicators to control the output from the R==1 tests.
Add helper check for "_R1" to indicate if instruction is coded with R==1.
Add init and print helpers for the pcrelative_write_target array.
The pstq instruction for R=1, was not using the correct effective address.
The EA_hi and EA_lo should have been based on the value of EA as calculated
by the function calculate_prefix_EA. Unfortuanely, the EA_hi and EA_lo
addresses were still using the previous code (not PC relative) to calculate
the address from the contants of RA plus the offset.
On some systems the gdbserver_tests would fail because the filter
for the optimized hwcaps subdir didn't match because the file is
called slightly differently, with the version number before .so
instead of after. For example: /lib64/glibc-hwcaps/power9/libc-2.28.so
Add one extra filter for this pattern.
The lxsibzx was doing a 64-bit load. The result was initializing
additional bytes in the register that should not have been initialized.
The memcheck/tests/linux/dlclose_leak test detected the issue. The
code generation uses lxsibzx and stxsibx with -mcpu=power9. Previously
the lbz and stb instructions were generated.
The same issue was noted and fixed with the lxsihzx instruction. The
memcheck/tests/linux/badrw test now passes as well.
https://bugs.kde.org/show_bug.cgi?id=444571
In s390_irgen_EXRL, the offset is zero-extended instead of sign-extended,
typically causing Valgrind to crash when a negative offset occurs.
Fix this with a new helper function that calculates a "relative long"
address from a 32-bit offset. Replace other calculations of "relative
long" addresses by invocations of this function as well. And for
consistency, do the same with "relative" (short) addresses.
Currently the version is updated in 3 places, configure.ac,
include/valgrind.h and docs/xml/vg-entities.xml. This goes wrong from
time to time. So only define the version (and release date) once in
configure.ac and update both other places at configure time.
Depending on architecture glibc has various functions that set things
up to call "main". glibc 2.34 added __libc_start_call_main (at least
on ppc64le and s390x). Other variants recognized are __libc_start_main,
generic_start_main and variants of those names.
This fixes the massif/tests/deep-D and massif/tests/mmapunmap on ppc64le.
Add demangler update, __libc_freeres not being called on fatal signal,
DWARF reader improvements, glibc 2.34 support and various new arm64
v8.2 updates.
Remove Tool Changes section, since there were no user visible
changes to the tools in 3.18.0.
Implement BPF_MAP_LOOKUP_AND_DELETE_ELEM (command 21) and
BPF_MAP_FREEZE (command 22) and produce a WARNING instead of a fatal
error for unrecognized BPF commands.
https://bugs.kde.org/show_bug.cgi?id=426148
This is a system call introduced in Linux 5.9.
It's typically used to bulk-close file descriptors that a process inherited
without having desired so and doesn't want to pass them to its offspring
for security reasons. For this reason the sensible upper limit value tends
to be unknown and the users prefer to stay on the safe side by setting it
high.
This is a bit peculiar because, if unfiltered, the syscall could end up
closing descriptors Valgrind uses for its purposes, ending in no end of
mayhem and suffering.
This patch adjusts the upper bounds to a safe value and then skips over
the descriptor Valgrind uses by potentially calling the real system call
with sub-ranges that are safe to close.
The call can fail on negative ranges and bad flags -- we're dealing with
the first condition ourselves while letting the real call fail on bad
flags.
https://bugs.kde.org/show_bug.cgi?id=439090
When a program gets a fatal signal (one it doesn't handle) valgrind
terminates the program. Before termination it will try to call
final_tidyup which tries to run __libc_freeres and
__gnu_cxx::__freeres to get rid of some memory glibc or libstdc++
don't normally release.
But when the program got the fatal signal in a critical section inside
glibc it might leave the datastructures in a bad state and cause
__libc_freeres to crash. This makes valgrind itself crash just before
producing its own error summary, making the valgrind run unusable.
A reproducer can found at
https://bugzilla.redhat.com/show_bug.cgi?id=1952836 and
https://bugzilla.redhat.com/show_bug.cgi?id=1225994#c7
This reproducer is really a worse case scenario with multiple threads
racing to get into the critical section that when interrupted will
make __libc_freeres unable to cleanup. But it seems a good policy in
general. If a program is terminated by a fatal signal instead of
normal termination, it seems not having some of the glibc/libstdc++
resource cleaned up is an expected thing.
https://bugs.kde.org/show_bug.cgi?id=443605
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.
The drd/tests/tc21_pthonce and drd/tests/annotate_barrier tests
would fail if start_thread came from libc (as it does in glibc 2.34)
instead of from libpthread. Extract start_thread in filter_stderr.in
and update the backtraces in annotate_barrier.stderr.exp and in
tc21_pthonce.stderr.exp
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.
libmpiwrap.c:1379:45: warning: format '%d' expects argument of type 'int',
but argument 5 has type 'MPI_Request' {aka 'struct ompi_request_t *'}
Unfortunately MPI_Request is an opaque type (we don't really know what
is in struct ompi_request_t) so we cannot simply print it as int. In
other places we print an MPI_Request as 0x%lx by casting it to an
unsigned long. Do the same here.
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.
cachegrind callgrind dhat exp-bbv gdbserver_tests massif none mpi shared
Mostly these are just updates (and new testcases) under new/tests
The other directories have just #ifdef changes
