[valgrind] [Bug 431157] PPC_FEATURE2_SCV needs to be masked in AT_HWCAP2
https://bugs.kde.org/show_bug.cgi?id=431157 --- Comment #17 from Mark Wielaard --- For now I have pushed this commit: commit ea98cccb4d50a8740708507c4c72cfb1e6c88e38 Author: Mark Wielaard Date: Tue Feb 23 16:19:26 2021 +0100 Filter out unsupported instructions from HWCAP2 on powerpc. Valgrind currently doesn't support the DARN random number instruction and the SCV syscall instruction. Filter them out of HWCAP2 so glibc and applications don't try to use them when running under valgrind. Also suppress printing a log message for scv instructions in the instruction stream. Reported by: Florian Weimer DARN bug: https://bugs.kde.org/show_bug.cgi?id=411189 SCV bug: https://bugs.kde.org/show_bug.cgi?id=431157 When SCV is implemented it can be added to HWCAPS2 again. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 431157] PPC_FEATURE2_SCV needs to be masked in AT_HWCAP2
https://bugs.kde.org/show_bug.cgi?id=431157 --- Comment #16 from Mark Wielaard --- (In reply to Carl Love from comment #15) > Created attachment 135371 [details] > patch to add support for the scv instruction > > Cleaned up formatting, spacing and a minor functional fix. Unfortunately this patch doesn't seem to work correctly on a ppc64le setup with linux 5.11.0 and glibc 2.32.9000, which uses SCV: LD_SHOW_AUXV=1 /bin/true AT_DCACHEBSIZE: 0x80 AT_ICACHEBSIZE: 0x80 AT_UCACHEBSIZE: 0x0 AT_SYSINFO_EHDR: 0x7fff905c AT_L1I_CACHESIZE: 32768 AT_L1I_CACHEGEOMETRY: 128B line size, 32-way set associative AT_L1D_CACHESIZE: 32768 AT_L1D_CACHEGEOMETRY: 128B line size, 32-way set associative AT_L2_CACHESIZE: 524288 AT_L2_CACHEGEOMETRY: 32B line size, 2048-way set associative AT_L3_CACHESIZE: 10485760 AT_L3_CACHEGEOMETRY: 32B line size, 40960-way set associative AT_HWCAP: true_le archpmu vsx arch_2_06 dfp ic_snoop smt mmu fpu altivec ppc64 ppc32 AT_PAGESZ:65536 AT_CLKTCK:100 AT_PHDR: 0x10f1b0040 AT_PHENT: 56 AT_PHNUM: 9 AT_BASE: 0x7fff905d AT_FLAGS: 0x0 AT_ENTRY: 0x10f1b1ad8 AT_UID: 0 AT_EUID: 0 AT_GID: 0 AT_EGID: 0 AT_SECURE:0 AT_RANDOM:0x7fffcd3e3272 AT_HWCAP2:scv darn ieee128 arch_3_00 vcrypto tar isel ebb dscr arch_2_07 AT_EXECFN:/bin/true AT_PLATFORM: power9 AT_BASE_PLATFORM: power9 A simple testcase: # LANG=en.UTF-8 ./vg-in-place /bin/true --help ==108495== Memcheck, a memory error detector ==108495== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==108495== Using Valgrind-3.17.0.GIT and LibVEX; rerun with -h for copyright info ==108495== Command: /bin/true --help ==108495== ==108495== Warning: invalid file descriptor -2 in syscall openat() ==108495== Invalid read of size 4 ==108495==at 0x492B7C0: _nl_load_locale_from_archive (in /usr/lib64/power9/libc-2.32.9000.so) ==108495==by 0x4929ECF: _nl_find_locale (in /usr/lib64/power9/libc-2.32.9000.so) ==108495==by 0x492945F: setlocale (in /usr/lib64/power9/libc-2.32.9000.so) ==108495==by 0x181963: ??? (in /usr/bin/true) ==108495==by 0x49195B3: generic_start_main.constprop.0.isra.0 (in /usr/lib64/power9/libc-2.32.9000.so) ==108495==by 0x491978F: (below main) (in /usr/lib64/power9/libc-2.32.9000.so) ==108495== Address 0x26 is not stack'd, malloc'd or (recently) free'd ==108495== ==108495== ==108495== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==108495== Access not within mapped region at address 0x26 ==108495==at 0x492B7C0: _nl_load_locale_from_archive (in /usr/lib64/power9/libc-2.32.9000.so) ==108495==by 0x4929ECF: _nl_find_locale (in /usr/lib64/power9/libc-2.32.9000.so) ==108495==by 0x492945F: setlocale (in /usr/lib64/power9/libc-2.32.9000.so) ==108495==by 0x181963: ??? (in /usr/bin/true) ==108495==by 0x49195B3: generic_start_main.constprop.0.isra.0 (in /usr/lib64/power9/libc-2.32.9000.so) ==108495==by 0x491978F: (below main) (in /usr/lib64/power9/libc-2.32.9000.so) ==108495== If you believe this happened as a result of a stack ==108495== overflow in your program's main thread (unlikely but ==108495== possible), you can try to increase the size of the ==108495== main thread stack using the --main-stacksize= flag. ==108495== The main thread stack size used in this run was 8388608. ==108495== ==108495== HEAP SUMMARY: ==108495== in use at exit: 0 bytes in 0 blocks ==108495== total heap usage: 1 allocs, 1 frees, 5 bytes allocated ==108495== ==108495== All heap blocks were freed -- no leaks are possible ==108495== ==108495== For lists of detected and suppressed errors, rerun with: -s ==108495== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ./vg-in-place: line 31: 108495 Segmentation fault (core dumped) VALGRIND_LIB="$vgbasedir/.in_place" VALGRIND_LIB_INNER="$vgbasedir/.in_place" "$vgbasedir/coregrind/valgrind" "$@" make regtest also shows various failures: == 638 tests, 44 stderr failures, 14 stdout failures, 0 stderrB failures, 0 stdoutB failures, 3 post failures == memcheck/tests/buflen_check (stderr) memcheck/tests/bug340392 (stderr) memcheck/tests/erringfds (stdout) memcheck/tests/erringfds (stderr) memcheck/tests/file_locking (stderr) memcheck/tests/leak_cpp_interior (stderr) memcheck/tests/linux/memfd (stderr) memcheck/tests/linux/rfcomm (stderr) memcheck/tests/linux/sys-execveat(stderr) memcheck/tests/linux/sys-openat (stderr) memcheck/tests/linux/sys-preadv_pwritev (stderr) memcheck/tests/linux/timerfd-syscall (stderr) memcheck/tests/null_socket (stdo
[valgrind] [Bug 433323] Use pkglibexecdir as vglibdir
https://bugs.kde.org/show_bug.cgi?id=433323 --- Comment #4 from Mark Wielaard --- Note that Debian only recently (2018) started following FHS 3.0 which allows libexec use. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834607 Which probably explains why it isn't yet widely used on Debian. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427510] Use of uninitialized value in callgrind_annotate.
https://bugs.kde.org/show_bug.cgi?id=427510 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #7 from Mark Wielaard --- I cannot replicate this issue, not even with the attachment 132259: $ callgrind_annotate callgrind.out.9703 > /dev/null Produces no warnings or errors. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432870] gdbserver_tests:nlcontrolc hangs with newest glibc2.33 x86-64
https://bugs.kde.org/show_bug.cgi?id=432870 --- Comment #5 from Mark Wielaard --- *** Bug 427931 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427931] gdbserver_tests/nlcontrolc.vgtest hangs on fedora rawhide
https://bugs.kde.org/show_bug.cgi?id=427931 Mark Wielaard changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Mark Wielaard --- *** This bug has been marked as a duplicate of bug 432870 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 356715] vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x7D 0x13 0x4 0x4A 0xC5 0xFC
https://bugs.kde.org/show_bug.cgi?id=356715 Mark Wielaard changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED CC||m...@klomp.org --- Comment #8 from Mark Wielaard --- This should be fixed in valgrind 3.15.0 by: commit 472b067e39a11a47ae3fa7cd7d3142558f78969d Author: Julian Seward Date: Sun Mar 17 21:41:42 2019 +0100 amd64: Implement RDRAND, VCVTPH2PS and VCVTPS2PH. Bug 398870 - Please add support for instruction vcvtps2ph Bug 353370 - RDRAND amd64->IR: unhandled instruction bytes: 0x48 0xF 0xC7 0xF0 This commit implements: * amd64 RDRAND instruction, on hosts that have it. * amd64 VCVTPH2PS and VCVTPS2PH, on hosts that have it. The presence/absence of these on the host is now reflected in the CPUID results returned to the guest. So code that tests for these features in CPUID and acts accordingly should "just work". * New test cases, none/tests/amd64/rdrand and none/tests/amd64/f16c. These are built if the host's assembler can handle them, in the usual way. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 356715] vex amd64->IR: unhandled instruction bytes: 0xC4 0xE2 0x7D 0x13 0x4 0x4A 0xC5 0xFC
https://bugs.kde.org/show_bug.cgi?id=356715 Mark Wielaard changed: What|Removed |Added CC||goffinet.franc...@gmail.com --- Comment #7 from Mark Wielaard --- *** Bug 427057 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427057] vex amd64->IR: unhandled instruction bytes: 0xC4 0xC2 0x7D 0x13 0x4 0x54 0xC4 0xE3 0x7D 0x19
https://bugs.kde.org/show_bug.cgi?id=427057 Mark Wielaard changed: What|Removed |Added Status|REPORTED|RESOLVED CC||m...@klomp.org Resolution|--- |DUPLICATE --- Comment #1 from Mark Wielaard --- This is VCVTPH2PS there is an open bug about it, but it might already have been fixed. 3.13 is fairly old. Please retry with a newer version (3.16.1 is the latest or if you can, please test against current git trunk). *** This bug has been marked as a duplicate of bug 356715 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388787] Support for C++17 new/delete
https://bugs.kde.org/show_bug.cgi?id=388787 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #7 from Mark Wielaard --- That is a big patch indeed. But mostly because it also adds support for libcxx and solaris. It looks good in general I believe. The ALLOC_or_NULL_ALIGNED now probably needs a ENOMEM check. The indentation in coregrind/m_scheduler/scheduler.c looks off (tabs vs spaces?) I think we need a configure check for whether the c++ compiler supports -std=c++17 for the testcase. Don't we also need new builtin_delete_aligned and builtin_vec_delete_aligned to get the new/malloc/free/delete mismatch correct? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 426148] Valgrind crash with "impossible happened" when running BPF CO-RE programs
https://bugs.kde.org/show_bug.cgi?id=426148 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #1 from Mark Wielaard --- eBPF command 22 is BPF_MAP_FREEZE. valgrind currently handle eBPF commands up to 20 (BPF_TASK_FD_QUERY), it doesn't yet handle some newer commands: BPF_MAP_LOOKUP_AND_DELETE_ELEM, /* 21 */ BPF_MAP_FREEZE, BPF_BTF_GET_NEXT_ID, BPF_MAP_LOOKUP_BATCH, BPF_MAP_LOOKUP_AND_DELETE_BATCH, BPF_MAP_UPDATE_BATCH, BPF_MAP_DELETE_BATCH, BPF_LINK_CREATE, BPF_LINK_UPDATE, BPF_LINK_GET_FD_BY_ID, BPF_LINK_GET_NEXT_ID, BPF_ENABLE_STATS, BPF_ITER_CREATE, BPF_LINK_DETACH, -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 424248] Doesn't support CLFLUSHOPT instruction
https://bugs.kde.org/show_bug.cgi?id=424248 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #2 from Mark Wielaard --- Note that you should check first with the cpuid feature flag CLFLUSHOPT whether the instruction is supported or not (valgrind doesn't set it). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 424149] Client requests to trigger snapshots
https://bugs.kde.org/show_bug.cgi?id=424149 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #1 from Mark Wielaard --- Running massif without automatic snapshots seems a little odd. But maybe it could be a command line flag so that it only snapshots from vgdb or through a client request? Do you have some example program that use the new client requests? Bonus points for one that can be used as new test and for documentation. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 323431] Unhandled AMD XOP instruction vpcmov VEX: unhandled instruction bytevex amd64->IR: 0x8F 0xE8 0x78 0xA2 0xC1 0x40 0xC5 0xFB
https://bugs.kde.org/show_bug.cgi?id=323431 Mark Wielaard changed: What|Removed |Added Blocks||339596 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=339596 [Bug 339596] AMD64 xop instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381819] amd64: unhandled instruction bextr (0x8F 0xEA 0x78 0x10 0xD0 0x8 0x4) from BMI1
https://bugs.kde.org/show_bug.cgi?id=381819 Mark Wielaard changed: What|Removed |Added Blocks||339596 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=339596 [Bug 339596] AMD64 xop instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 339596] AMD64 xop instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9
https://bugs.kde.org/show_bug.cgi?id=339596 Mark Wielaard changed: What|Removed |Added Depends on||323431, 381819 --- Comment #24 from Mark Wielaard --- Note there is also a bug (with patch) for XOP vpcmov here: https://bugs.kde.org/show_bug.cgi?id=323431 And a TBM bextr (which also uses the XOP prefix) bug (with patch) here: https://bugs.kde.org/show_bug.cgi?id=381819 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=323431 [Bug 323431] Unhandled AMD XOP instruction vpcmov VEX: unhandled instruction bytevex amd64->IR: 0x8F 0xE8 0x78 0xA2 0xC1 0x40 0xC5 0xFB https://bugs.kde.org/show_bug.cgi?id=381819 [Bug 381819] amd64: unhandled instruction bextr (0x8F 0xEA 0x78 0x10 0xD0 0x8 0x4) from BMI1 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 323431] Unhandled AMD XOP instruction vpcmov VEX: unhandled instruction bytevex amd64->IR: 0x8F 0xE8 0x78 0xA2 0xC1 0x40 0xC5 0xFB
https://bugs.kde.org/show_bug.cgi?id=323431 --- Comment #9 from Mark Wielaard --- Note there is a more generic XOP bug, also with patch at https://bugs.kde.org/show_bug.cgi?id=339596 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 424034] amd64->IR: unhandled instruction bytes: 0x8F 0xE9 0xF8 0x9B 0x5 0x5B 0x61 0xC 0x0 0xB8
https://bugs.kde.org/show_bug.cgi?id=424034 Mark Wielaard changed: What|Removed |Added Status|REPORTED|RESOLVED CC||m...@klomp.org Resolution|--- |DUPLICATE --- Comment #6 from Mark Wielaard --- Indeed, this is the XOP VPSHAQ Packed Shift Arithmetic Quadwords instruction. *** This bug has been marked as a duplicate of bug 339596 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 339596] AMD64 xop instructions unsupported. vex amd64->IR: unhandled instruction bytes: 0x8F 0xE8 0x78 0xCD 0xC1 0x4 0xC5 0xF9
https://bugs.kde.org/show_bug.cgi?id=339596 Mark Wielaard changed: What|Removed |Added CC||joseph.jenn...@gmail.com --- Comment #23 from Mark Wielaard --- *** Bug 424034 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 361770] Missing F_ADD_SEALS
https://bugs.kde.org/show_bug.cgi?id=361770
Mark Wielaard changed:
What|Removed |Added
Resolution|--- |FIXED
CC||m...@klomp.org
Status|REPORTED|RESOLVED
--- Comment #5 from Mark Wielaard ---
Sorry this took so long. Especially since the patch was perfect.
Pushed as:
commit dec30506534c0c1bb0e77e62275e697b041e3c3a
Author: Allison Karlitskaya
Date: Tue Oct 13 13:17:11 2020 +0200
Linux: Add wrapper for fcntl(F_{GET,ADD}_SEALS)
Add also a testcase to memcheck/tests/linux, enabled according to a new
check for memfd_create() in configure.ac.
https://bugs.kde.org/show_bug.cgi?id=361770
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 429952] Errors when building regtest with clang
https://bugs.kde.org/show_bug.cgi?id=429952 --- Comment #4 from Mark Wielaard --- commit af0a901b4ed8625afd26891b4c91d7dd9ea6ba45 Author: Paul Floyd Date: Tue Dec 8 14:59:49 2020 +0100 Bug 429952 - Errors when building regtest with clang -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 428716] VEX/useful/smchash.c:39:16: error: Memory leak: gb [memleak]
https://bugs.kde.org/show_bug.cgi?id=428716 --- Comment #8 from Mark Wielaard --- commit 7967aea84b920d304b99fab60a612740854bd877 Author: Paul Floyd Date: Sun Nov 8 08:00:36 2020 +0100 Bug 478716 - cppcheck detects potential leak in VEX/useful/smchash.c -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 424012] Valgrind crashes with readv/writev having invalid but not NULL arg2 iovec pointer
https://bugs.kde.org/show_bug.cgi?id=424012 --- Comment #6 from Mark Wielaard --- commit 3aa3482774cf99ba23b7a6eac97d17cf143af5aa Author: Paul Floyd Date: Mon Nov 9 09:30:31 2020 +0100 Bug 424012 - fix crash if readv/writev have invalid but not NULL arg2 iovec pointer -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 391853] Makefile.all.am:L247 and @SOLARIS_UNDEF_LARGESOURCE@ being empty
https://bugs.kde.org/show_bug.cgi?id=391853 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #2 from Mark Wielaard --- commit 8caab853a75c020fe546c4ceafb6f7e52326a18a Author: Paul Floyd Date: Wed Jan 6 10:57:11 2021 +0100 Bug 391853 - Makefile.all.am:L247 and @SOLARIS_UNDEF_LARGESOURCE@ being empty -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 433323] Use pkglibexecdir as vglibdir
https://bugs.kde.org/show_bug.cgi?id=433323 --- Comment #3 from Mark Wielaard --- (In reply to Tom Hughes from comment #2) > Note that libexec usage varies quite a bit across distros - it's not used > much on Ubuntu for example but is on Fedora. Yes, I have been using it on Fedora for some time (since 3.16.0 at least). But it should be distro independent. And is more in spirit of the FHS and how automake intends pkglibdir vs pkglibexecdir to be used. > Bizarrely valgrind is one of the few packages that does seem to use libexec > on Ubuntu, but only for the DHAT html/js/css files, which seems very odd. I think it depends on how you look at those files. Note that we used to also install those under pkglibdir, which also seemed wrong/weird. If you see them as executables (which at least the js/css are) intended to be run by other programs (webbrowsers) then libexec makes sense. But maybe there is a different standard place to install those programs? Where they are installed is controlled by the dhatdir variable defined in dhat/Makefile.am. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384729] __libc_freeres inhibits cross-platform valgrind
https://bugs.kde.org/show_bug.cgi?id=384729 --- Comment #10 from Mark Wielaard --- commit 35c9c33897ef89b08e1518ed16244e70bc6996da Author: Paul Floyd Date: Mon Nov 9 16:31:40 2020 +0100 Bug 384729 - __libc_freeres inhibits cross-platform valgrind -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 433323] Use pkglibexecdir as vglibdir
https://bugs.kde.org/show_bug.cgi?id=433323 Mark Wielaard changed: What|Removed |Added Status|REPORTED|ASSIGNED Assignee|jsew...@acm.org |m...@klomp.org Ever confirmed|0 |1 --- Comment #1 from Mark Wielaard --- Created attachment 135964 --> https://bugs.kde.org/attachment.cgi?id=135964=edit Use pkglibexec as vglibdir -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 433323] New: Use pkglibexecdir as vglibdir
https://bugs.kde.org/show_bug.cgi?id=433323 Bug ID: 433323 Summary: Use pkglibexecdir as vglibdir Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: m...@klomp.org Target Milestone: --- vglibdir is the directory from where valgrind loads its internal executables, vgpreload and static tools. Currently vglibdir is pkglibdir, so those internal tools are intermingeled with normal executables and libraries that the user might use directly. Make vglibdir equal to pkglibexecdir so the internal tools get installed and loaded from libexec and don't get get stored under lib. This leaves just the static archives and the mpiwrapper libraries that the user would link/load themselves under lib. This seems more in line with the FHS lib/libexec standard and makes it slightly easier to combine the tools from a multilib target (say the memcheck-amd64-linux and memcheck-x86-linux tools) because they would be installed under the same directory, while the pkglibdir can differ depending on arch/target (lib/lib64). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 217695] realloc failure doesn't set errno to ENOMEM
https://bugs.kde.org/show_bug.cgi?id=217695 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Mark Wielaard --- commit 1c9a0bf58a47e855e6e5bf78a30bcee0af835804 Author: Mark Wielaard Date: Fri Feb 12 23:29:34 2021 +0100 PR217695 malloc/calloc/realloc/memalign failure doesn't set errno to ENOMEM 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 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432870] gdbserver_tests:nlcontrolc hangs with newest glibc2.33 x86-64
https://bugs.kde.org/show_bug.cgi?id=432870 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #2 from Mark Wielaard --- Thanks for tracking this down to that specific glibc commit. It changes which select system call is called depending on the architecture and kernel version. This might be related to https://bugs.kde.org/show_bug.cgi?id=338633 where we disable the nlcontrolc.vgtest on arm64 because it hangs (speculated to be because arm64 doesn't provide a traditional select system call). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 217695] realloc failure doesn't set errno to ENOMEM
https://bugs.kde.org/show_bug.cgi?id=217695 Mark Wielaard changed: What|Removed |Added Status|REPORTED|ASSIGNED Ever confirmed|0 |1 Assignee|jsew...@acm.org |m...@klomp.org --- Comment #3 from Mark Wielaard --- Created attachment 135649 --> https://bugs.kde.org/attachment.cgi?id=135649=edit Set (glibc) errno to ENOMEM when malloc/calloc/realloc/memalign fail This turned out to be less hard than I assumed. We already have a trick for calling functions which might only be defined in glibc. The idea is to define the symbol as weak in out preload library. It will then be NULL unless some other library defines it for real. Then we can simply call it when it is non-NULL (and only when one of the allocation functions returns NULL). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432809] VEX should support REX.W + POPF
https://bugs.kde.org/show_bug.cgi?id=432809 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #4 from Mark Wielaard --- commit e2e830f61271c28dddfa6b478044870d2188cf57 Author: Mark Wielaard Date: Fri Feb 12 20:42:00 2021 +0100 PR432809 VEX should support REX.W + POPF It seems a REX.W prefix simply explicitly sets the operant size to 8, and so can/must be ignored as redundant. This is what we already do for PUSH, POP and PUSHF. All instructions are described as "When in 64-bit mode, instruction defaults to 64-bit operand size and cannot encode 32-bit operand size." in the instruction manual. Original patch and analysis by Mike Dalessio https://bugs.kde.org/show_bug.cgi?id=432809 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432215] Add debuginfod functionality
https://bugs.kde.org/show_bug.cgi?id=432215 --- Comment #9 from Mark Wielaard --- Do we really need to redirect stderr to a temporary file and then use grep to filter out any errors? If possible it would be nicer if we could simply do one exec and simply drain stderr from the process till it is done and then read stdout, which is always just one line with the file path. Did you try that? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432215] Add debuginfod functionality
https://bugs.kde.org/show_bug.cgi?id=432215
--- Comment #8 from Mark Wielaard ---
+ if (VG_(getenv)("DEBUGINFOD_URLS") == NULL
+ || VG_(strcmp)("", VG_(getenv("DEBUGINFOD_URLS"))) == 0)
+ return NULL;
+
+ if ((path = ML_(find_executable)("debuginfod-find")) == NULL)
+ return NULL;
It would be nice to move this somewhere so that it only has to be checked ones.
Maybe something like:
static
const HChar* debuginfod_find_path (void)
{
static const HChar *path = (const HChar*) -1;
if (path == (const HChar*) -1) {
if (VG_(getenv)("DEBUGINFOD_URLS") == NULL
|| VG_(strcmp)("", VG_(getenv("DEBUGINFOD_URLS"))) == 0)
path = NULL;
else
path = ML_(find_executable)("debuginfod-find");
}
return path;
}
So you can check as
if ((path = debuginfod_find_path()) == NULL)
return NULL;
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 432215] Add debuginfod functionality
https://bugs.kde.org/show_bug.cgi?id=432215 --- Comment #7 from Mark Wielaard --- The patch includes some changes to tests/vg_regtest.in. I believe they aren't needed anymore because you already submitted them in bug #432672. Or is the explicit clearing of DEBUGINFOD_URLS still needed? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432215] Add debuginfod functionality
https://bugs.kde.org/show_bug.cgi?id=432215 --- Comment #6 from Mark Wielaard --- Random comment that isn't really about the actual patch: +#include "../m_initimg/priv_initimg_pathscan.h" I see you need this for ML_(find_executable). Maybe this should moved somewhere else so you don't need to import a priv header from another module. Maybe it can be moved into coregrind/m_libcproc.c and the files that need it then include pub_core_libcproc.h ? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432809] VEX should support REX.W + POPF
https://bugs.kde.org/show_bug.cgi?id=432809
Mark Wielaard changed:
What|Removed |Added
Status|REPORTED|CONFIRMED
Ever confirmed|0 |1
--- Comment #3 from Mark Wielaard ---
I checked. PUSH and POP do always upgrade sz == 4 to sz = 8 but allow sz == 8
too. PUSHF actually has a note about having seen a dedundant REX prefix:
case 0x9C: /* PUSHF */ {
/* Note. There is no encoding for a 32-bit pushf in 64-bit
mode. So sz==4 actually means sz==8. */
/* 24 July 06: has also been seen with a redundant REX prefix,
so must also allow sz==8. */
We don't handle sz == 8 for LEAVE. But reading the instruction manual that
seems tricky since it has to match the size operand of the corresponding ENTER
(where we also don't handle sz == 8).
In summary, I think the patch is correct.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 432809] VEX should support REX.W + POPF
https://bugs.kde.org/show_bug.cgi?id=432809 --- Comment #2 from Mark Wielaard --- (In reply to Mark Wielaard from comment #1) > We had something similar in bug #422174 with REX prefixed JMP instructions. > Lets see what the instruction manual says... It says (for PUSH, POP, PUSHF/D/Q, POPF/D/Q and LEAVE): "When in 64-bit mode, instruction defaults to 64-bit operand size and cannot encode 32-bit operand size." Which is explains the sz == to sz = 8 "upgrade" we always do. It seems a REX.W prefix simply explicitly sets the operant size to 8, and so can/must be ignored as redundant. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432809] VEX should support REX.W + POPF
https://bugs.kde.org/show_bug.cgi?id=432809 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #1 from Mark Wielaard --- We had something similar in bug #422174 with REX prefixed JMP instructions. Lets see what the instruction manual says... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432672] vg_regtest: test-specific environment variables not reset between tests
https://bugs.kde.org/show_bug.cgi?id=432672 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Mark Wielaard --- Thanks for finding this. Your fix looks correct to me. Pushed as: commit 208f2d96069574e7a75cb3f8e53adb216e4795b9 Author: Mark Wielaard Date: Thu Feb 11 18:29:52 2021 +0100 vg_regtest: test-specific environment variables not reset between tests Test-specific environment variables set in .vgtest files are not reset between tests. This can result in tests running with environment variables intended for a previously run test. This can be easily fixed by clearing the @env and @envB arrays in tests/vg_regtest:read_vgtest_file() Original patch by Aaron Merey https://bugs.kde.org/show_bug.cgi?id=432672 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432801] Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals
https://bugs.kde.org/show_bug.cgi?id=432801 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #1 from Mark Wielaard --- The actual instruction that produces the Conditional jump or move warning is relevant. Could you post the complete disassembly of main? Does that disassembly differ between a working and non-working version? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432510] RFE: ENOMEM fault injection mode
https://bugs.kde.org/show_bug.cgi?id=432510 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #1 from Mark Wielaard --- This is a nice idea. One tricky thing is that although the malloc-like functions can return NULL they don't actually set errno. See https://bugs.kde.org/show_bug.cgi?id=217695 this may or may not be a problem for this idea. There is a brief description on how the malloc replacement functions work at ./docs/internals/m_replacemalloc.txt I am not sure what the right "level" is to implement this. The choices are: - ./coregrind/m_replacemalloc/vg_replace_malloc.c This is where the malloc-like functions are intercepted. The code runs as part of the program (is LD_PRELOADED). Which means you cannot easily call into the valgrind core. But you can simply replace any malloc-like call with a (random) return of NULL which would then work with any valgrind tool that uses malloc replacement. - In a specific tool like in memcheck/mc_malloc_wrappers.c See the VG_(needs_malloc_replacement) call in memcheck/mc_main.c to see which malloc like functions are wrapped (MC_(malloc), MC_(calloc), MC_(realloc), etc.) most of these call into MC_(new_block). Which you could conditionally return NULL based on the tool (memcheck in this case) state. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 140939] --track-fds reports leakage of stdout/in/err and doesn't respect -q
https://bugs.kde.org/show_bug.cgi?id=140939 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Mark Wielaard --- commit c9781cc97e719c1ecf0cfad9ca2f86631c017268 Author: Mark Wielaard Date: Mon Feb 8 00:25:52 2021 +0100 PR140939 --track-fds reports leakage of stdout/in/err and doesn't respect -q Make --track-fds=yes not report on file descriptors 0, 1, and 2 (stdin, stdout, and stderr) by default. Add a new option --track-fds=all that does report on the std file descriptors still being open. Update testsuite and documentation. Original patch by Peter Kelly Updated by Daniel Fahlgren https://bugs.kde.org/show_bug.cgi?id=140939 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 217695] realloc failure doesn't set errno to ENOMEM
https://bugs.kde.org/show_bug.cgi?id=217695 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #2 from Mark Wielaard --- (In reply to Ashe David Goulding from comment #1) > Can be reproducible by calling `calloc()` with values that would result in > overflow. All the dynamic memory allocation system calls(malloc, calloc, > realloc) set `errno` to ENOMEM when they return NULL. This is POSIX > compliant. > > Granted, no one checks errno. We all assume that allocation failed when the > functions return NULL. But there are use cases where errno is used for > diagnostic purposes. That's how I found this bug anyway. > > This bug is 11 years old. Would someone please at least give this bug a > verdict? I'd take WONTFIX as an answer. In theory this (setting errno to ENOMEM on an allocation function returning NULL) could be supported. But it is not that easy to do correct without knowing how the libc the program is running against handles errno. In practice this is always glibc, so maybe we can try. To show why this is non-trivial from errno(3): errno is defined by the ISO C standard to be a modifiable lvalue of type int, and must not be explicitly declared; errno may be a macro. And glibc defines it as: extern int *__errno_location (void) __THROW __attribute__ ((__const__)); #define errno (*__errno_location ()) Now the malloc intercepts actually run on the simulated cpu (see coregrind/m_replacemalloc/vg_replace_malloc.c) and could in theory use the above definition to set errno to ENOMEM in ALLOC_or_NULL (when NULL). But that would make that vg_replace_malloc rely on a libc that has the magic __errno_location function. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 140939] --track-fds reports leakage of stdout/in/err and doesn't respect -q
https://bugs.kde.org/show_bug.cgi?id=140939 Mark Wielaard changed: What|Removed |Added Attachment #125774|0 |1 is obsolete|| Status|REPORTED|ASSIGNED Ever confirmed|0 |1 Assignee|jsew...@acm.org |m...@klomp.org CC||m...@klomp.org --- Comment #7 from Mark Wielaard --- Created attachment 135494 --> https://bugs.kde.org/attachment.cgi?id=135494=edit Patch including --track-fds=all, testsuite updates and documentation For some reason this keeps being dropped while it is a good idea and people approve of the fix. I updated the patch a little to include a new variant --track-fds=all which does include tracking/reporting on stdin/out/err. It also updates the testsuite and documentation. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 140178] open("/proc/self/exe, ...); doesn't quite work
https://bugs.kde.org/show_bug.cgi?id=140178 Mark Wielaard changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Mark Wielaard --- Tested as part of https://bugzilla.redhat.com/show_bug.cgi?id=1925786 commit 57c823aefea32e1fba3af47d29e66313d0bc13cd Author: Mark Wielaard Date: Sat Feb 6 22:02:56 2021 +0100 PR140178 Support opening /proc/self/exe Some programs open /proc/self/exe to read some data. Currently valgrind supports following the /proc/self/exe link (to the original binary, so you could then open that), but directly opening /proc/self/exe will open the valgrind tool, not the executable file itself. Add ML_(handle_self_exe_open) which dups VG_(cl_exec_fd) if the file to open is /proc/self/exe or /proc//exe. And do the same for openat. https://bugs.kde.org/show_bug.cgi?id=140178 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 140178] open("/proc/self/exe, ...); doesn't quite work
https://bugs.kde.org/show_bug.cgi?id=140178 --- Comment #5 from Mark Wielaard --- Created attachment 135476 --> https://bugs.kde.org/attachment.cgi?id=135476=edit Updated patch that also handle openat The fix needs to handle both the open and openat syscalls. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 140178] open("/proc/self/exe, ...); doesn't quite work
https://bugs.kde.org/show_bug.cgi?id=140178 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #4 from Mark Wielaard --- Created attachment 135468 --> https://bugs.kde.org/attachment.cgi?id=135468=edit Handle open /proc/self/exe Also reported at https://bugzilla.redhat.com/show_bug.cgi?id=1925786 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 410743] shmat() calls for 32-bit programs fail when running in 64-bit valgrind
https://bugs.kde.org/show_bug.cgi?id=410743 Mark Wielaard changed: What|Removed |Added CC||gand...@winds.org --- Comment #9 from Mark Wielaard --- *** Bug 423929 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 423929] shmat() fails in x86 32-bit mode on valgrind 3.16.0 & 3.16.1
https://bugs.kde.org/show_bug.cgi?id=423929 Mark Wielaard changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE CC||m...@klomp.org --- Comment #3 from Mark Wielaard --- *** This bug has been marked as a duplicate of bug 410743 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 423361] Adds io_uring support on arm64/aarch64
https://bugs.kde.org/show_bug.cgi?id=423361 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #1 from Mark Wielaard --- Thanks, it looks like at least these 3 io_uring_setup, io_uring_enter and io_uring_register were added everywhere (arm, arm64, mips, powerpc, s390). And we already have them in vki-scnums-shared-linux.h BTW. You are right, KDE uses gitlab, but valgrind doesn't. commit b918f710208889d579026627830a80b24be1513d Author: Mark Wielaard Date: Thu Feb 4 17:21:56 2021 +0100 PR423361 Adds io_uring support on arm64/aarch64 (and all other arches) io_uring syscalls only work on x86/amd64, but they can be enabled on all arches. Based on a patch by Nathan Ringo . https://bugs.kde.org/show_bug.cgi?id=423361 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 421262] Lack of Proper (80 bit) Long Double Support Causes Serious Problems (on x86 32/64bit)
https://bugs.kde.org/show_bug.cgi?id=421262 Mark Wielaard changed: What|Removed |Added Summary|Lack of Proper (80 bit) |Lack of Proper (80 bit) |Long Double Support Causes |Long Double Support Causes |Serious Problems (on x86|Serious Problems (on x86 |32bit) |32/64bit) --- Comment #3 from Mark Wielaard --- (In reply to Chris Wilson from comment #2) > Someone changed the title of this bug report I submitted to say "x86 32bit" > in the title. Actually, I'm using 64-bit, not 32-bit, x86, and that is > where I encountered the problem. That someone was me. I just wanted to have the bug properly titled. I don't think anybody is working on this (patches welcome of course). But lets keep this bug open to signal there are some people interested in this. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 421262] Lack of Proper (80 bit) Long Double Support Causes Serious Problems (on x86 32bit)
https://bugs.kde.org/show_bug.cgi?id=421262 Mark Wielaard changed: What|Removed |Added Summary|Lack of Proper Long Double |Lack of Proper (80 bit) |Support Causes Serious |Long Double Support Causes |Problems|Serious Problems (on x86 ||32bit) CC||m...@klomp.org -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 422261] platform selection fails for unqualified client name
https://bugs.kde.org/show_bug.cgi?id=422261 Mark Wielaard changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Mark Wielaard --- commit f7e87e6ae3497287ceac6ef266d4f10ee8ab3c53 Author: Mark Wielaard Date: Thu Feb 4 16:14:00 2021 +0100 PR422261 platform selection fails for unqualified client name Bug introduced with commit f15beea76 "Fix memory leak in launcher-linux.c" Need to try opening the actual 'client' path, not just the 'clientname' file name. Reported-by: Michael Wojcik https://bugs.kde.org/show_bug.cgi?id=422261 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 422261] platform selection fails for unqualified client name
https://bugs.kde.org/show_bug.cgi?id=422261 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #1 from Mark Wielaard --- Thanks for the report. It seems I accidentally introduced this bug with: commit f15beea767892ae52ed1d92d789114685fb5dc82 Author: Mark Wielaard Date: Sat May 25 16:31:02 2019 +0200 Fix memory leak in launcher-linux.c When the clientname argument is not a full absolute path we reconstruct the full path using $PATH. This reconstructed full path would be leaked. This is small and insignificant. But valgrind should give a good example. So free the path again when we are done and allocated the memory. Also don't print the path twice in the debug output if we didn't need to construct a new different path for it. I am not sure why this wasn't noticed earlier because your example clearly shows it failing. I guess 32-on-64 arch runs are just not done that much or always involve a relative or absolute path? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 410743] shmat() calls for 32-bit programs fail when running in 64-bit valgrind
https://bugs.kde.org/show_bug.cgi?id=410743
Mark Wielaard changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution|--- |FIXED
--- Comment #8 from Mark Wielaard ---
Tested on x86 (32bit) and arm64 (64bit) and pushed as two separate commits:
commit 889bffd9860337720a00cce888648b2262177ff2
Author: Anssi Hannula
Date: Thu Jul 2 14:49:17 2020 +0300
Fix shmat() on Linux nanomips and x86
On Linux, there are two variants of the direct shmctl syscall:
- sys_shmctl: always uses shmid64_ds, does not accept IPC_64
- sys_old_shmctl: uses shmid_ds or shmid64_ds depending on IPC_64
The following Linux ABIs have the sys_old_shmctl variant:
alpha, arm, microblaze, mips n32/n64, xtensa
Other ABIs (and future ABIs) have the sys_shmctl variant, including ABIs
that only got sys_shmctl in Linux 5.1 (such as x86, mips o32, ppc,
s390x).
We incorrectly assume the sys_old_shmctl variant on nanomips and x86,
causing shmat() calls under valgrind to fail with EINVAL.
On x86, the issue was previously masked by the non-existence of
__NR_shmctl until a9fc7bceeb0b0 ("Update Linux x86 system call number
definitions") in 2019.
On mips o32, ppc, and s390x this issue is not visible as our headers do
not have __NR_shmctl for those ABIs (396 since Linux 5.1).
Fix the issue by correcting the preprocessor check in get_shm_size() to
only assume the old Linux sys_old_shmctl behavior on the specific
affected platforms.
Also, exclude the use of direct shmctl entirely on Linux x86, ppc,
mips o32, s390x in order to keep compatibility with pre-5.1 kernel
versions that did not yet have direct shmctl for those ABIs.
This currently only has actual effect on x86 as only it has __NR_shmctl
in our headers.
Fixes tests mremap4, mremap5, mremap6.
https://bugs.kde.org/show_bug.cgi?id=410743
commit 7ada4d26d7cd3eb14904a398e6646f8b4e7d8a64
Author: Mark Wielaard
Date: Wed Feb 3 16:56:14 2021 +0100
syswrap-linux.c: Pass implicit VKI_IPC_64 for shmctl also on arm64.
The shmctl syscall on amd64, arm64 and riscv (but we don't have a port
for that last one) always use IPC_64. Explicitly pass it to the generic
PRE/POST handlers so they select the correct (64bit) data structures on
those architectures.
https://bugzilla.redhat.com/show_bug.cgi?id=1909548
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 410743] shmat() calls for 32-bit programs fail when running in 64-bit valgrind
https://bugs.kde.org/show_bug.cgi?id=410743
--- Comment #7 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #6)
> This looks similar to what is reported against Fedora arm64:
> https://bugzilla.redhat.com/show_bug.cgi?id=1909548
It isn't exactly the same issue. But related.
The issue in that bug is that syswrap-linux.c calls generic_PRE_sys_shmctl and
generic_POST_sys_shmctl with an extra VKI_IPC_64 only for amd64_linux, but not
for arm64_linux. In both cases (and riscv, but we don't have a port for that)
the VKI_IPC_64 is implied. The fix for that is simply:
diff --git a/coregrind/m_syswrap/syswrap-linux.c
b/coregrind/m_syswrap/syswrap-linux.c
index 328e02a98..52074149d 100644
--- a/coregrind/m_syswrap/syswrap-linux.c
+++ b/coregrind/m_syswrap/syswrap-linux.c
@@ -5127,7 +5127,7 @@ PRE(sys_shmctl)
PRINT("sys_shmctl ( %ld, %ld, %#" FMT_REGWORD "x )", SARG1, SARG2, ARG3);
PRE_REG_READ3(long, "shmctl",
int, shmid, int, cmd, struct shmid_ds *, buf);
-#ifdef VGP_amd64_linux
+#if defined(VGP_amd64_linux) || defined(VGP_arm64_linux)
ML_(generic_PRE_sys_shmctl)(tid, ARG1,ARG2|VKI_IPC_64,ARG3);
#else
ML_(generic_PRE_sys_shmctl)(tid, ARG1,ARG2,ARG3);
@@ -5136,7 +5136,7 @@ PRE(sys_shmctl)
POST(sys_shmctl)
{
-#ifdef VGP_amd64_linux
+#if defined(VGP_amd64_linux) || defined(VGP_arm64_linux)
ML_(generic_POST_sys_shmctl)(tid, RES,ARG1,ARG2|VKI_IPC_64,ARG3);
#else
ML_(generic_POST_sys_shmctl)(tid, RES,ARG1,ARG2,ARG3);
Then the generic PRE/POST do the right thing selecting the correct data
structure size.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 410743] shmat() calls for 32-bit programs fail when running in 64-bit valgrind
https://bugs.kde.org/show_bug.cgi?id=410743 Mark Wielaard changed: What|Removed |Added See Also||https://bugzilla.redhat.com ||/show_bug.cgi?id=1909548 --- Comment #6 from Mark Wielaard --- This looks similar to what is reported against Fedora arm64: https://bugzilla.redhat.com/show_bug.cgi?id=1909548 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432215] Add debuginfod functionality
https://bugs.kde.org/show_bug.cgi?id=432215 --- Comment #4 from Mark Wielaard --- (In reply to Aaron Merey from comment #3) > (In reply to Mark Wielaard from comment #1) > > - I think you need to drain stderr first in a while loop before doing the > > VG_(waitpid)(pid, NULL, 0); and VG_(read)(out_fds[0], buf, BUF_SIZE); > > because based if the user has set DEBUGINFOD_PROGRESS or DEBUGINFOD_VERBOSE > > stderr can see a lot of output (stdout is always just the filename if > > anything was found). > > Good point. It may be easier to simply redirect debuginfod-find's stderr to > a temporary file to avoid any complications with the pipe filling up. The > error message can instead be read from that file if needed. You might have to experiment with how that interacts with the DEBUGINFOD_PROGRESS output. It might be that VG_(umsg) and "interactive" stderr from the inferior don't really mix anyway. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432215] Add debuginfod functionality
https://bugs.kde.org/show_bug.cgi?id=432215 --- Comment #2 from Mark Wielaard --- Also I think all the VG_(umsg) need to be guarded by if (VG_(clo_verbosity) > 0) so that there is no extra output when running with valgrind -q. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432215] Add debuginfod functionality
https://bugs.kde.org/show_bug.cgi?id=432215
Mark Wielaard changed:
What|Removed |Added
Status|REPORTED|CONFIRMED
Ever confirmed|0 |1
CC||m...@klomp.org,
||philippe.waroquiers@skynet.
||be
--- Comment #1 from Mark Wielaard ---
Nice. Adding Philippe to CC because he probably knows most about executing
subprocesses from valgrind core.
My first comments would be:
- It would be nice to not even try if the system doesn't have debuginfod-find
installed or if DEBUGINFOD_URLS is not set or empty. You can check the second
with VG_(getenv)("DEBUGINFOD_URLS") and the first by taking out
ML_(find_executable)("debuginfod-find")) from the new function and setting a
static debuginfo_find_path variable in slightly earlier startup code. You would
also set debuginfo_find_path to NULL if DEBUGINFOD_URLS wouldn't be set.
- I think you need to drain stderr first in a while loop before doing the
VG_(waitpid)(pid, NULL, 0); and VG_(read)(out_fds[0], buf, BUF_SIZE); because
based if the user has set DEBUGINFOD_PROGRESS or DEBUGINFOD_VERBOSE stderr can
see a lot of output (stdout is always just the filename if anything was found).
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 432102] Support DWARF5
https://bugs.kde.org/show_bug.cgi?id=432102 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #1 from Mark Wielaard --- Julian looked at it briefly on irc and gave me a star. Pushed as: commit a1fa6696f5f3714983438647285ce85262d101b3 Author: Mark Wielaard Date: Mon Jan 25 15:33:34 2021 +0100 Add support for DWARF5 as produced by GCC11 Implement DWARF5 in readdwarf.c and readdwarf3.c Since gcc11 will default to DWARF5 by default it is time for valgrind to support it. The patch handles everything gcc11 produces (except for the new DWARF expressions). There is some duplication in the patch since we actually have two DWARF readers which use slightly different abstractions (Slices vs Cursors). It would be nice if we could merge these somehow. The reader in readdwarf3.c is only used when --read-var-info=yes is used (which drd uses to provide the allocation context). The handling of DW_FORM_implicit_const is tricky with the current design. An abbrev which contains an attribute encoded with DW_FORM_implicit_const has its value also in the abbrev. The code in readdwarf3.c assumed it always could simply get the data from the .debug_info/current Cursor. For now I added a value field to the name_form field that holds the associated value. This is slightly wasteful since the extra field is not necessary for other forms. Tested against GCC10 (defaulting to DWARF4) and GCC11 (defaulting to DWARF5) on x86_64. No regressions in the regtests. https://bugs.kde.org/show_bug.cgi?id=432102 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388706] warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf2 (DW_OP_GNU_implicit_pointer)
https://bugs.kde.org/show_bug.cgi?id=388706 Mark Wielaard changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #3 from Mark Wielaard --- This (and DW_OP_GNU_entry_value) are still not handled. We are not seeing this in our testsuite because tests/filter_stderr_basic contains: # Suppress warnings from Dwarf reader sed '/warning: evaluate_Dwarf3_Expr: unhandled DW_OP_/d' Note for DWARF5 these GNU extensions are standardized as DW_OP_implicit_pointer = 0xa0 and DW_OP_entry_value = 0xa3 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432102] New: Support DWARF5
https://bugs.kde.org/show_bug.cgi?id=432102 Bug ID: 432102 Summary: Support DWARF5 Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: m...@klomp.org Target Milestone: --- Created attachment 135171 --> https://bugs.kde.org/attachment.cgi?id=135171=edit Implement DWARF5 in readdwarf and readdwarf3 Since gcc11 will default to DWARF5 by default it is time for valgrind to support it. The attached patch handles everything gcc11 produces. There is some duplication in the patch since we actually have two DWARF readers which use slightly different abstractions (Slices vs Cursors). It would be nice if we could merge these somehow. And the handling of DW_FORM_implicit_const is tricky with the current design. An abbrev which contains an attribute encoded with DW_FORM_implicit_const has its value also in the abbrev. The code in readdwarf3.c assumed it always could simply get the data from the .debug_info/current Cursor. For now I added a value field to the name_form field that holds the associated value. This is slightly wasteful since the extra field is not necessary for other forms. Tested against GCC10 and GCC11 on x86_64. No regressions in the regtests. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 431157] PPC_FEATURE2_SCV needs to be masked in AT_HWCAP2
https://bugs.kde.org/show_bug.cgi?id=431157 --- Comment #11 from Mark Wielaard --- (In reply to Florian Weimer from comment #10) > What's the status here? The first glibc release with scv support is coming > up. Thanks. The status is still as in comment #7. There is a workaround (filtering out the HWCAP2 bits) in the valgrind Fedora package, but nothing yet is upstream. Carl, what do you think? Should we go with the HWCAP2 filtering, can we make the SCV syscall working and/or both at the same time. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 431157] PPC_FEATURE2_SCV needs to be masked in AT_HWCAP2
https://bugs.kde.org/show_bug.cgi?id=431157 --- Comment #8 from Mark Wielaard --- For reference, this explains the (newer) powerpc syscall conventions of the linux kernel: https://www.kernel.org/doc/html/v5.10/powerpc/syscall64-abi.html -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 431157] PPC_FEATURE2_SCV needs to be masked in AT_HWCAP2
https://bugs.kde.org/show_bug.cgi?id=431157 --- Comment #7 from Mark Wielaard --- For now I have backported Florian's patch to the Fedora rawhide valgrind package to get things unstuck: https://koji.fedoraproject.org/koji/buildinfo?buildID=182 I had to tweak the patch a little to remove the references to isa 3.1 (power10) plus the PREFIX checks. I did remove/filter the PPC_FEATURE2_ARCH_3_1 flag, but didn't touch any other (I believe valgrind does support HTM on power, but I don't know what HTM_NOSC is). Also, see https://bugs.kde.org/show_bug.cgi?id=422683 do we also need to filter AT_PLATFORM/AT_BASE_PLATFORM ? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 431157] PPC_FEATURE2_SCV needs to be masked in AT_HWCAP2
https://bugs.kde.org/show_bug.cgi?id=431157 --- Comment #5 from Mark Wielaard --- That looks plausible: +/* Mask unrecognized HWCAP bits. Only keep the bits that have + * been mentioned above. + */ +auxv->u.a_val &= 0xfec4ULL; So if I understand correctly that means (of those not mentioned above) explicitly filtered out: PPC_FEATURE2_HTM_NOSC 0x0100 PPC_FEATURE2_DARN 0x0020 PPC_FEATURE2_SCV 0x0010 explicitly included: PPC_FEATURE2_ARCH_3_1 0x0004 It might make sense to have defines of these in include/vki/vki-ppc64-linux.h as VKI_PPC_FEATURE2_* so that we can more easily see which ones we include/exclude. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 431157] PPC_FEATURE2_SCV needs to be masked in AT_HWCAP2
https://bugs.kde.org/show_bug.cgi?id=431157 Mark Wielaard changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #3 from Mark Wielaard --- So this is basically two bugs. 1) Newer kernels set the auxv AT_HWCAP2 bit which indicates SCV syscall support and could potentially set other capability bits for cpu instructions/features valgrind doesn't support, so we might want to proactively filter/clean AT_HWCAPS2 as is don't for some other architectures in coregrind/m_initimg/initimg-linux.c (setup_client_stack). 2) We want to support SCV syscall support. Which is the attached patch, but since the calling convention/return/error value reporting is different between sc and scv 0, the attached patch is not a complete implementation. When we have a complete implementation, then the filtering for 1) would change. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 431157] PPC_FEATURE2_SCV needs to be masked in AT_HWCAP2
https://bugs.kde.org/show_bug.cgi?id=431157 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381819] amd64: unhandled instruction bextr (0x8F 0xEA 0x78 0x10 0xD0 0x8 0x4) from BMI1
https://bugs.kde.org/show_bug.cgi?id=381819 Mark Wielaard changed: What|Removed |Added CC||dcb...@hotmail.com --- Comment #24 from Mark Wielaard --- *** Bug 430866 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 430866] vex amd64->IR: unhandled instruction bytes: 0x8F 0x4A 0x78 0x10 0xE4 0x5 0x1 0x0 0x0 0xE9
https://bugs.kde.org/show_bug.cgi?id=430866 Mark Wielaard changed: What|Removed |Added Status|REPORTED|RESOLVED CC||m...@klomp.org Resolution|--- |DUPLICATE --- Comment #1 from Mark Wielaard --- Another bextr variant *** This bug has been marked as a duplicate of bug 381819 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381819] amd64: unhandled instruction bextr (0x8F 0xEA 0x78 0x10 0xD0 0x8 0x4) from BMI1
https://bugs.kde.org/show_bug.cgi?id=381819 Mark Wielaard changed: What|Removed |Added CC||nuquaquara...@gmail.com --- Comment #23 from Mark Wielaard --- *** Bug 385477 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 385477] AMD64, sqlite3 - Unrecognised instruction: bextr
https://bugs.kde.org/show_bug.cgi?id=385477 Mark Wielaard changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #3 from Mark Wielaard --- *** This bug has been marked as a duplicate of bug 381819 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 430485] expr_is_guardable doesn't handle Iex_Qop
https://bugs.kde.org/show_bug.cgi?id=430485 Mark Wielaard changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Mark Wielaard --- commit 42ef710e1928275c98ff72cd82bc5e6b05fe8295 Author: Mark Wielaard Date: Tue Dec 22 14:51:15 2020 +0100 expr_is_guardable doesn't handle Iex_Qop IRExpr_Qop uses the Iex_Qop tag, which expr_is_guardable didn't handle. https://bugs.kde.org/show_bug.cgi?id=430485 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 430597] unhandled amd64-linux syscall: 315
https://bugs.kde.org/show_bug.cgi?id=430597 --- Comment #14 from Mark Wielaard --- This looks like a QT/VMWare graphics issue https://bugreports.qt.io/browse/QTBUG-69993 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369029] WARNING: unhandled amd64-linux syscall: 315 (sched_getattr)
https://bugs.kde.org/show_bug.cgi?id=369029 --- Comment #19 from Mark Wielaard --- *** Bug 430597 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 430597] unhandled amd64-linux syscall: 315
https://bugs.kde.org/show_bug.cgi?id=430597 Mark Wielaard changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #8 from Mark Wielaard --- *** This bug has been marked as a duplicate of bug 369029 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 430597] unhandled amd64-linux syscall: 315
https://bugs.kde.org/show_bug.cgi?id=430597 Mark Wielaard changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Mark Wielaard --- Try the current git version of valgrind and/or a version that has that commit backported. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 397605] ioctl FICLONE mishandled
https://bugs.kde.org/show_bug.cgi?id=397605 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Mark Wielaard --- Apologies this patch lingered so long. It does look correct, I replicated the issue and your analysis of how the _IOW uapi definition is misleading also seems correct. Pushed as: commit 1c49351424f04ee29a5efc054cb08ab3ad22b978 Author: Laurent Bonnans Date: Fri Nov 16 15:22:18 2018 +0100 Fix 397605 - Add support for Linux FICLONE ioctl -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 430597] unhandled amd64-linux syscall: 315
https://bugs.kde.org/show_bug.cgi?id=430597 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org Resolution|FIXED |DUPLICATE --- Comment #5 from Mark Wielaard --- Specifically this was: commit 6323fd5bfd94c3f80e2ff44f16488e0172bd9a96 Author: Mark Wielaard Date: Mon Jul 27 16:36:17 2020 +0200 Handle linux syscalls sched_getattr and sched_setattr The only "special" thing about these syscalls is that the given struct sched_attr determines its own size for future expansion. Original fix by "ISHIKAWA,chiaki" https://bugs.kde.org/show_bug.cgi?id=369029 *** This bug has been marked as a duplicate of bug 369029 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 369029] WARNING: unhandled amd64-linux syscall: 315 (sched_getattr)
https://bugs.kde.org/show_bug.cgi?id=369029 Mark Wielaard changed: What|Removed |Added CC||hymu...@gmail.com --- Comment #18 from Mark Wielaard --- *** Bug 430597 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 430485] New: expr_is_guardable doesn't handle Iex_Qop
https://bugs.kde.org/show_bug.cgi?id=430485 Bug ID: 430485 Summary: expr_is_guardable doesn't handle Iex_Qop Product: valgrind Version: unspecified Platform: Other URL: https://bugzilla.redhat.com/show_bug.cgi?id=1844910 OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: m...@klomp.org Target Milestone: --- After implementing Iop_MAdd/Sub for arm64 (bug #426014) we got a report that "the impossible happened": > MSubF64(t15,t21,t22,t23) > vex: the `impossible' happened: >expr_is_guardable: unhandled expr > vex storage: T total 3295105024 bytes allocated > vex storage: P total 0 bytes allocated > > valgrind: the 'impossible' happened: >LibVEX called failure_exit(). And indeed expr_is_guardable doesn't handle Iex_Qop the tag IRExpr_Qop uses. It seems something like the following should work (currently untested): diff --git a/VEX/priv/guest_generic_bb_to_IR.c b/VEX/priv/guest_generic_bb_to_IR.c index 0cee970e4..1e72ddacd 100644 --- a/VEX/priv/guest_generic_bb_to_IR.c +++ b/VEX/priv/guest_generic_bb_to_IR.c @@ -422,6 +422,8 @@ static Bool expr_is_guardable ( const IRExpr* e ) return !primopMightTrap(e->Iex.Binop.op); case Iex_Triop: return !primopMightTrap(e->Iex.Triop.details->op); + case Iex_Qop: + return !primopMightTrap(e->Iex.Qop.details->op); case Iex_ITE: case Iex_CCall: case Iex_Get: I am just surprised this hasn't come up before since other arches (ppc, s390) also implement scalar FMA operations. Some more background in https://bugzilla.redhat.com/show_bug.cgi?id=1844910 (the fedora valgrind package has the arm64 fma patch backported). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 430484] New: none/tests/arm64/atomics_v81 occassionally fails
https://bugs.kde.org/show_bug.cgi?id=430484 Bug ID: 430484 Summary: none/tests/arm64/atomics_v81 occassionally fails Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: m...@klomp.org CC: assad.has...@linaro.org, peter.mayd...@linaro.org Target Milestone: --- Sometimes, but of course not when I explicitly try, none/tests/arm64/atomics_v81 fails with: cat none/tests/arm64/atomics_v81.stdout.diff --- atomics_v81.stdout.exp 2020-12-11 07:29:26.440663198 -0500 +++ atomics_v81.stdout.out 2020-12-16 17:09:36.965817433 -0500 @@ -15318,7 +15318,7 @@ caspal x8, x9, x10, x11, [x5] :: rs rt 0123456789abcdef 0123456789abcdef rn mem caspal x8, x9, x10, x11, [x5] :: rs rt 0123456789abcdef 0123456789abcdef rn mem -caspal x8, x9, x10, x11, [x5] :: rs rt 0123456789abcdef 0123456789abcdef rn mem 0123456789abcdef 0123456789abcdef +caspal x8, x9, x10, x11, [x5] :: rs rt 0123456789abcdef 0123456789abcdef rn mem FAIL: swapped but mem after != rt caspal x8, x9, x10, x11, [x5] :: rs rt fedcba9876543210 fedcba9876543210 rn mem caspal x8, x9, x10, x11, [x5] :: rs rt fedcba9876543210 fedcba9876543210 rn mem EXPECTED RESULT cpuinfo says: processor : 0 BogoMIPS: 400.00 Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics cpuid asimdrdm CPU implementer : 0x43 CPU architecture: 8 CPU variant : 0x1 CPU part: 0x0af CPU revision: 1 processor : 1 BogoMIPS: 400.00 Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics cpuid asimdrdm CPU implementer : 0x43 CPU architecture: 8 CPU variant : 0x1 CPU part: 0x0af CPU revision: 1 processor : 2 BogoMIPS: 400.00 Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics cpuid asimdrdm CPU implementer : 0x43 CPU architecture: 8 CPU variant : 0x1 CPU part: 0x0af CPU revision: 1 processor : 3 BogoMIPS: 400.00 Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics cpuid asimdrdm CPU implementer : 0x43 CPU architecture: 8 CPU variant : 0x1 CPU part: 0x0af CPU revision: 1 It failed 2 times when trying ~30 times (the 2 times were the first run and the 8th run). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 426014] arm64: implement fmadd and fmsub as Iop_MAdd/Sub instead of Iop_Add plus Iop_Mul
https://bugs.kde.org/show_bug.cgi?id=426014
Mark Wielaard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
--- Comment #7 from Mark Wielaard ---
Pushed the patch with one small change. I replaced
none/tests/arm64/fmadd_sub.stdout.exp with the exact output of running
none/tests/arm64/fmadd_sub on bare metal. Now that we fixed the -0.0/+0.0 sign
issues the result running under valgrind must be identical to running without.
commit 04cdc29b007594a0e58ffef0c9dd87df3ea595ea
Author: Mark Wielaard
Date: Wed Oct 14 06:11:34 2020 -0400
arm64 VEX frontend and backend support for Iop_M{Add,Sub}F{32,64}
The arm64 frontend used to implement the scalar fmadd, fmsub, fnmadd
and fnmsub iinstructions into separate addition/substraction and
multiplication instructions, which caused rounding issues.
This patch turns them into Iop_M{Add,Sub}F{32,64} instructions
(with some arguments negated). And the backend now emits fmadd or fmsub
instructions.
Alexandra Hajkova added tests and fixed up the
implementation to make sure rounding (and sign) are correct now.
https://bugs.kde.org/show_bug.cgi?id=426014
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 426014] arm64: implement fmadd and fmsub as Iop_MAdd/Sub instead of Iop_Add plus Iop_Mul
https://bugs.kde.org/show_bug.cgi?id=426014 Mark Wielaard changed: What|Removed |Added Attachment #134086|0 |1 is obsolete|| Status|REPORTED|ASSIGNED Ever confirmed|0 |1 Assignee|ahajk...@redhat.com |m...@klomp.org --- Comment #6 from Mark Wielaard --- Created attachment 134093 --> https://bugs.kde.org/attachment.cgi?id=134093=edit patch Thanks. Cleaned up the patch a little amd added a few more comments in the commit message. - Removed the standalone tests_fmadd/sub32/64.c tests in the top level dir. - Updated the SPEC/IMPL comment to show how we implement it now using fmadd and fmsub - Removed the now unused opADD, opSUB, opMUL and eNxM - Reindented the ix switch statement -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 430354] ppc stxsibx and stxsihx instructions write too much data
https://bugs.kde.org/show_bug.cgi?id=430354 Mark Wielaard changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Mark Wielaard --- commit ab257bc49a6c8beefa794470446f917ec441f718 Author: Mark Wielaard Date: Tue Dec 15 11:49:58 2020 +0100 ppc stxsibx and stxsihx instructions write too much data stxsibx (Store VSX Scalar as Integer Byte Indexed X-form) is implemented by first reading a whole word, merging in the new byte, and then writing out the whole word. Causing memcheck to warn when the destination might have room for less than 8 bytes. The stxsihx (Store VSX Scalar as Integer Halfword Indexed X-form) instruction does something similar reading and then writing a full word instead of a half word. The code can be simplified (and made more correct) by storing the byte (or half-word) directly, IRStmt_Store seems fine to store byte or half word sized data, and so seems the ppc backend. https://bugs.kde.org/show_bug.cgi?id=430354 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 430354] ppc stxsibx and stxsihx instructions write too much data
https://bugs.kde.org/show_bug.cgi?id=430354 --- Comment #1 from Mark Wielaard --- Created attachment 134060 --> https://bugs.kde.org/attachment.cgi?id=134060=edit Implement stxsibx and stxsihx as direct byte or half-word store This implements stxsibx and stxsihx as direct byte or half-word stores of 8 or 16 bytes without first reading the whole word at the effective address. This fixes the issue with memcheck/tests/str_tester and some other string functions and doesn't seem to produce any regressions. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 430354] New: ppc stxsibx and stxsihx instructions write too much data
https://bugs.kde.org/show_bug.cgi?id=430354 Bug ID: 430354 Summary: ppc stxsibx and stxsihx instructions write too much data Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: m...@klomp.org CC: c...@us.ibm.com, will_schm...@vnet.ibm.com Target Milestone: --- On a system with a power9 optimized glibc memcheck/tests/str_tester (and any other application using some of the glibc string functions) fail with: ==473431== Invalid write of size 8 ==473431==at 0x419C4CC: strndup (strndup.c:48) ==473431==by 0x1000B08F: test_strndup (str_tester.c:1297) ==473431==by 0x1000C043: main (str_tester.c:1528) ==473431== Address 0x4300046 is 6 bytes inside a block of size 7 alloc'd ==473431==at 0x40A428C: malloc (vg_replace_malloc.c:307) ==473431==by 0x419C4B3: strndup (strndup.c:43) ==473431==by 0x1000B08F: test_strndup (str_tester.c:1297) ==473431==by 0x1000C043: main (str_tester.c:1528) Looking with gdb finds: 0x0419c4cc in __GI___strndup (s=0x1000c418 "abcdef", n=) at strndup.c:48 48new[len] = '\0'; Dump of assembler code for function __GI___strndup: 0x0419c480 <+0>: addis r2,r12,22 0x0419c484 <+4>: addir2,r2,-20864 0x0419c488 <+8>: mflrr0 0x0419c48c <+12>:std r30,-16(r1) 0x0419c490 <+16>:std r31,-8(r1) 0x0419c494 <+20>:std r0,16(r1) 0x0419c498 <+24>:stdur1,-48(r1) 0x0419c49c <+28>:mr r30,r3 0x0419c4a0 <+32>:bl 0x41ae390 <__strnlen_ppc> 0x0419c4a4 <+36>:nop 0x0419c4a8 <+40>:mr r31,r3 0x0419c4ac <+44>:addir3,r3,1 0x0419c4b0 <+48>:bl 0x4118cc0 <0025.plt_call.malloc> 0x0419c4b4 <+52>:ld r2,24(r1) 0x0419c4b8 <+56>:mr. r9,r3 0x0419c4bc <+60>:beq 0x419c4dc <__GI___strndup+92> 0x0419c4c0 <+64>:xxspltib vs0,0 0x0419c4c4 <+68>:mr r4,r30 0x0419c4c8 <+72>:mr r5,r31 => 0x0419c4cc <+76>:stxsibx vs0,r9,r31 0x0419c4d0 <+80>:bl 0x4118c80 <0025.plt_call.__GI_memcpy> 0x0419c4d4 <+84>:ld r2,24(r1) 0x0419c4d8 <+88>:mr r9,r3 0x0419c4dc <+92>:addir1,r1,48 0x0419c4e0 <+96>:mr r3,r9 0x0419c4e4 <+100>: ld r0,16(r1) 0x0419c4e8 <+104>: ld r30,-16(r1) 0x0419c4ec <+108>: ld r31,-8(r1) 0x0419c4f0 <+112>: mtlrr0 0x0419c4f4 <+116>: blr 0x0419c4f8 <+120>: .long 0x0 0x0419c4fc <+124>: .long 0x100 0x0419c500 <+128>: .long 0x280 End of assembler dump. So it is using stxsibx to write one byte at the end of the string. But stxsibx is implemented by first reading a whole word, merging in the new byte, and then writing out the whole word. Causing memcheck to warn the wrote is beyond the end of (malloced) string buffer. The the stxsihx (Store VSX Scalar as Integer Halfword Indexed X-form) instruction does something similar. It isn't immediately clear why the code isn't just storing the byte directly, IRStmt_Store seems fine to store byte or half word sized data, and so seems the ppc backend. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 430158] New: below main misses some "optimizations"
https://bugs.kde.org/show_bug.cgi?id=430158
Bug ID: 430158
Summary: below main misses some "optimizations"
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: massif
Assignee: n...@valgrind.org
Reporter: m...@klomp.org
Target Milestone: ---
gcc can do a couple more optimizations for generic_start_main, like
generic_start_main.isra.0 or generic_start_main.constprop.0.isra.0.
For ppc we already recognize generic_start_main.isra.0, but nothing else.
It would probably be good to recognize any optimization in get_fnname_kind like
so:
# if defined(VGO_linux)
VG_STREQ("__libc_start_main", name) || // glibc glibness
VG_STREQ("generic_start_main", name) || // Yellow Dog doggedness
VG_STREQN(19, "generic_start_main.", name) || // gcc optimization
# elif defined(VGO_darwin)
This fixes ./massif/tests/deep-D.vgtest on same setups, and we could then get
rid of ./massif/tests/deep-D.post.diff-ppc64
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 408663] Patch: Suppression file for musl libc
https://bugs.kde.org/show_bug.cgi?id=408663 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #3 from Mark Wielaard --- If this has been tested on a distro that actually uses musl as default libc, this seems fine. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 382083] Failure to detect MUSL consistently.
https://bugs.kde.org/show_bug.cgi?id=382083 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #2 from Mark Wielaard --- I am not sure how well musl libc is supported in the first place. It seems alpine linux is the only distro that has it as default, so if your change doesn't work for them then that seems not good. There must be a better way to detect musl at configure time. Since we need to know about various internals of the C library to properly function, it would be nice to have a more solid test. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 429952] Errors when building regtest with clang
https://bugs.kde.org/show_bug.cgi?id=429952 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #3 from Mark Wielaard --- If this helps your build then I think this is fine. But note that your patch doesn't actually include the new filter_lambda file. Please add it before committing. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 404076] s390x: z14 vector instructions not implemented
https://bugs.kde.org/show_bug.cgi?id=404076 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org --- Comment #9 from Mark Wielaard --- To facilitate wider testing I have backported this patch to the Fedora 33 and rawhide valgrind package. Things look good, but my own testing was done on a setup that didn't have the (z14) vxe facility, so all I can personally conclude is that it doesn't introduce any regressions. https://bodhi.fedoraproject.org/updates/FEDORA-2020-62b0db3640 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414268] Enable AArch64 feature detection and decoding for v8.x instructions (where x>0)
https://bugs.kde.org/show_bug.cgi?id=414268 --- Comment #12 from Mark Wielaard --- (In reply to ahashmi from comment #11) > > Since programs can also check features through the attribute/feature > > registers, do we also need to filter those when inspected by the guest code? > Hmm...I don't see why we should. We aim to faithfully support features > detected, so if guest code reads those it should expect Valgrind to support > it. If Valgrind doesn't, it means we haven't yet implemented support for > that feature. (If I understand your question correctly.) So the question is not about this particular patch. But how we signal to the guest process which features valgrind/VEX supports itself. If the guest code checks the auxv HW_CAPS we are good because we filter out any features not implemented. But if the guest code checks attribute/feature registers it might get the attributes/features supported by the host. But if valgrind/VEX doesn't support those and the guest tries to use them it will get a SIGILL instead of trying to use fallback code. So it seems to me we also need a way to filter the attribute/feature registers to only advertise those armv8 instructions we actually implement. That is what other arches do too (see for example the dirtyhelper_CPUID in guest_x86_helpers.c or the s390x_dirtyhelper_vec_op). IMHO we should only pass through any bits set in these registers if we actually have implemented them (and preemptively zero out any future reserved ones). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414268] Enable AArch64 feature detection and decoding for v8.x instructions (where x>0)
https://bugs.kde.org/show_bug.cgi?id=414268 Mark Wielaard changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #10 from Mark Wielaard --- OK with the latest patch the machine that crashed now simply says: Arch and hwcaps: ARM64, LittleEndian, v8 It does allow reading ID_AA64ISAR0_EL1 register but doesn't seem to have any features we care for (from /proc/cpuinfo): Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid I know too little about arm64 to know whether or not we should care about these. I see we already filter on these in the auxv AT_HWCAP. Once we support, and not just test, some of these new features we should forget to add them to the AT_HWCAP filter. Since programs can also check features through the attribute/feature registers, do we also need to filter those when inspected by the guest code? Or do we already do that? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 428909] helgrind: need to intercept duplicate libc definitions for Fedora 33
https://bugs.kde.org/show_bug.cgi?id=428909 --- Comment #20 from Mark Wielaard --- (In reply to Paul Floyd from comment #18) > Created attachment 133799 [details] > Add configure time checking > > This patch now uses configure. The tests are fairly complicated, but seem to > work OK for Fedora 33, Alpine Linux (musl), Solaris 11.3 and FreeBSD. > However, I don't get what I expect for macOS. I only have access to 1 mac > running 10.7 to test this on, and Apple's libc/libpthread are rather > different and change fairly often. > > Bottom line is that I'm not entirely sure that this is better than the > prvious patch. I find the logic in the previous patch much easier to follow. The configure tests look complex/fragile. Also I am not sure the first ac_thread_fns_only_in_libc=yes is correct. Why couldn't those (or other) functions then not also be in libpthread? Normally I would agree with Bart, but I think this is one example of when configure tests are actually harder to keep correct than the simple ifdefs based on platform. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 428909] helgrind: need to intercept duplicate libc definitions for Fedora 33
https://bugs.kde.org/show_bug.cgi?id=428909 Mark Wielaard changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #19 from Mark Wielaard --- (In reply to Paul Floyd from comment #14) > Created attachment 133729 [details] > Try to make clearer conditional macros > > I've split the possibilities into > > VG_WRAP_THREAD_FUNCTION_LIBPTHREAD_ONLY > VG_WRAP_THREAD_FUNCTION_LIBC_ONLY > and > VG_WRAP_THREAD_FUNCTION_LIBC_AND_LIBPTHREAD > > This now affects redir.c and DRD drd_pthread_intercepts.c, which I changet > to keep consistent. > > MUSL no longer uses VG_Z_LIBPTHREAD_SONAME to refer to libc.* Shouldn't that first #if defined(VGO_darwin) in drd_pthread_intercepts.c be #if defined(VG_WRAP_THREAD_FUNCTION_LIBPTHREAD_ONLY) ? Otherwise looks good. This looks good, thanks. I am testing this with Fedora 33+ now. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 427870] lmw, lswi and related PowerPC insns aren't allowed on ppc64le
https://bugs.kde.org/show_bug.cgi?id=427870 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #3 from Mark Wielaard --- commit 74b74174d572fee4015b8f4e326db3cd949bcdc3 Author: Mark Wielaard Date: Tue Dec 1 14:57:39 2020 +0100 lmw, lswi and related PowerPC insns aren't allowed on ppc64le Newer binutils produce an error when the assembly contains lmw, stmw, lswi, lswx, stswi, or stswx instructions in little-endian mode. Only build and run the lsw and ldst_multiple testcases on ppc64[be]. https://bugs.kde.org/show_bug.cgi?id=427870 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 428909] helgrind: need to intercept duplicate libc definitions for Fedora 33
https://bugs.kde.org/show_bug.cgi?id=428909 --- Comment #13 from Mark Wielaard --- OK, I think I finally understand your patch, the alias is needed as declaration, but then you still need to define the implementation. In drd the implementation is done by calling one of the arguments of the macro, but in helgrind the implementation follows the macro as a function body, so you cannot refer to it in the PTH_FUNC macro itself. I am still somewhat unclear on why it needs to be a weak alias, but I understand at least why you want an function alias and cannot simply declare two functions in the helgrind case. -- You are receiving this mail because: You are watching all bug changes.
