[valgrind] [Bug 486180] [Valgrind][MIPS] 'VexGuestArchState' has no member named 'guest_IP_AT_SYSCALL'
https://bugs.kde.org/show_bug.cgi?id=486180
--- Comment #4 from Paul Floyd ---
m_scheduler/scheduler.c: In function ���handle_extension���:
m_scheduler/scheduler.c:1238:32: error: ���VexGuestArchState��� {aka ���struct
���} has no member named ���guest_IP_AT_SYSCALL���
Addr addr = tst->arch.vex.guest_IP_AT_SYSCALL;
^
make[3]: *** [Makefile:6562:
m_scheduler/libcoregrind_mips64_linux_a-scheduler.o] Error 1
make[3]: Leaving directory '/home/paulf/valgrind/coregrind'
make[2]: *** [Makefile:2557: all] Error 2
make[2]: Leaving directory '/home/paulf/valgrind/coregrind'
make[1]: *** [Makefile:918: all-recursive] Error 1
make[1]: Leaving directory '/home/paulf/valgrind'
make: *** [Makefile:781: all] Error 2
on mips32
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 486180] [Valgrind][MIPS] 'VexGuestArchState' has no member named 'guest_IP_AT_SYSCALL'
https://bugs.kde.org/show_bug.cgi?id=486180
--- Comment #2 from Paul Floyd ---
Almost certainly the problem is that VEX/pub/libvex_guest_mips{32,64}.h are
missing U{Int,Long} guest_IP_AT_SYSCALL plus maybe something to initialize
them.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 486180] [Valgrind][MIPS] 'VexGuestArchState' has no member named 'guest_IP_AT_SYSCALL'
https://bugs.kde.org/show_bug.cgi?id=486180 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr --- Comment #1 from Paul Floyd --- Do you get the error from a clean clone of Valgrind? If it’s from an old git repo, does running ‘make distclean’ and ‘autogen.sh’ then configure and make work? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 412377] SIGILL on cache flushes on arm64
https://bugs.kde.org/show_bug.cgi?id=412377 Paul Floyd changed: What|Removed |Added Assignee|jsew...@acm.org |pjfl...@wanadoo.fr -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 486093] -Wstrict-aliasing in tests
https://bugs.kde.org/show_bug.cgi?id=486093 Paul Floyd changed: What|Removed |Added Assignee|jsew...@acm.org |pjfl...@wanadoo.fr -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 486093] -Wstrict-aliasing in tests
https://bugs.kde.org/show_bug.cgi?id=486093 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr --- Comment #2 from Paul Floyd --- There is of course a load of intentional UB in the test cases. But this looks unintentional. The risk is that compilers start to exploit the UB for optimization and the code then breaks. Rather than using illegal type casts the code should use memcpy (or even better std::bit_cast but that requires C++20). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485778] Crash with --track-fds=all and --gen-suppressions=all
https://bugs.kde.org/show_bug.cgi?id=485778 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485778] New: Crash with --track-fds=all and --gen-suppressions=all
https://bugs.kde.org/show_bug.cgi?id=485778 Bug ID: 485778 Summary: Crash with --track-fds=all and --gen-suppressions=all Classification: Developer tools Product: valgrind Version: 3.23 GIT Platform: Compiled Sources OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: pjfl...@wanadoo.fr Target Milestone: --- I just noticed this warning In file included from pub_core_basics.h:38, from m_errormgr.c:29: m_errormgr.c: In function 'gen_suppression': ../include/pub_tool_basics.h:68:30: warning: 'name' may be used uninitialized in this function [-Wmaybe-uninitialized] 68 | #define VG_(str)VGAPPEND(vgPlain_, str) | ^~~~ m_errormgr.c:367:17: note: 'name' was declared here 367 |const HChar* name; | And I ran a few tests. In the "none/tests" directory ../../vg-in-place --track-fds=all --tool=none --gen-suppressions=all ./fdleak_creat --32134-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --32134-- si_code=1; Faulting address: 0x6; sp: 0x100288dc00 valgrind: the 'impossible' happened: Killed by fatal signal host stacktrace: ==32134==at 0x5801EB51: myvprintf_str (m_debuglog.c:742) ==32134==by 0x5801F4D6: vgPlain_debugLog_vprintf (m_debuglog.c:1146) ==32134==by 0x58008207: vgPlain_xaprintf (m_xarray.c:383) ==32134==by 0x58020DE9: gen_suppression (m_errormgr.c:397) ==32134==by 0x580226EA: pp_Error (m_errormgr.c:546) ==32134==by 0x58022F71: vgPlain_unique_error (m_errormgr.c:919) ==32134==by 0x5806FAA3: vgPlain_show_open_fds (syswrap-generic.c:980) ==32134==by 0x5801633B: shutdown_actions_NORETURN (m_main.c:2317) ==32134==by 0x5807C06A: run_a_thread_NORETURN (syswrap-linux.c:202) Are we planning on adding suppressions to core errors? If so this message will also need to change: ==32134== Bad option: --gen-suppressions=yes ==32134== Can't use --gen-suppressions= with Nulgrind ==32134== because it doesn't generate errors. ==32134== Use --help for more information or consult the user manual. (it says it can't use it and then it does use it!) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485276] std::optional use: "Conditional jump or move depends on uninitialised value(s)" (clang) aarch64
https://bugs.kde.org/show_bug.cgi?id=485276
--- Comment #6 from Paul Floyd ---
│ 244 _LIBCPP_INLINE_VISIBILITY
│ 245 _LIBCPP_CONSTEXPR_SINCE_CXX20 ~__optional_destruct_base()
│ 246 {
│ > 247 if (__engaged_)
│ 248 __val_.~value_type();
│ 249 }
Not sure what is happening. The error occurs as above, but it's not just
__engaged_ that is not initialized, this points to an uninitialized object.
(gdb) mc xb &__engaged_ sizeof(__engaged_)
ff
0x1FF8F0: 0x60
(gdb) mc xb this sizeof(*this)
00 ff ff ff ff ff ff ff
0x1FF8E0: 0x000x000x000x000x000x000x000x00
ff ff ff ff ff ff ff ff
0x1FF8E8: 0x000x000x000x000x000x000x000x00
ff ff ff ff ff ff ff ff
0x1FF8F0: 0x600xf90xff0xff0x1f0x000x000x00
type = struct std::__1::__optional_destruct_base [with _Tp =
dummy] {
union {
char __null_state_;
value_type __val_;
};
bool __engaged_;
public:
~__optional_destruct_base(void);
__optional_destruct_base(void);
void reset(void);
typedef _Tp value_type;
}
'this' points to memory on the stack which is why it's safe to dereference.
I'm not familiar with the code, but as I understand it, this is the key
function:
static Bool stmt_is_guardable ( const IRStmt* st )
{
switch (st->tag) {
// These are easily guarded.
case Ist_NoOp:
case Ist_IMark:
case Ist_Put:
case Ist_PutI:
return True;
// These are definitely not guardable, or at least it's way too much
// hassle to do so.
case Ist_CAS:
case Ist_LLSC:
case Ist_MBE:
return False;
// These could be guarded, with some effort, if really needed, but
// currently aren't guardable.
case Ist_LoadG:
case Ist_Store:
case Ist_StoreG:
case Ist_Exit:
case Ist_Dirty:
return False;
// This is probably guardable, but it depends on the RHS of the
// assignment.
case Ist_WrTmp:
return expr_is_guardable(st->Ist.WrTmp.data);
default:
vex_printf("\n"); ppIRStmt(st); vex_printf("\n");
vpanic("stmt_is_guardable: unhandled stmt");
}
}
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 485276] std::optional use: "Conditional jump or move depends on uninitialised value(s)" (clang) aarch64
https://bugs.kde.org/show_bug.cgi?id=485276 --- Comment #5 from Paul Floyd --- I can reproduce this on FreBSD 14 arm64 with clang++ 18.0.0 ==14165== Conditional jump or move depends on uninitialised value(s) ==14165==at 0x210A30: ~__optional_destruct_base (optional:247) ==14165==by 0x210A30: dummy_or_default() (bug485276.cpp:23) ==14165==by 0x210A9F: main (bug485276.cpp:28) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481874] Add arm64 support for FreeBSD
https://bugs.kde.org/show_bug.cgi?id=481874 Paul Floyd changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #19 from Paul Floyd --- commit 26924849826afac5de630916d9fb516a270a51ee (HEAD -> master, origin/master, origin/HEAD) Author: Paul Floyd Date: Tue Apr 16 07:39:33 2024 +0200 Bug 481874 - Add arm64 support for FreeBSD -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481874] Add arm64 support for FreeBSD
https://bugs.kde.org/show_bug.cgi?id=481874 --- Comment #18 from Paul Floyd --- (In reply to Mark Wielaard from comment #17) > .git-blame-ignore-revs references a clang-format rev that doesn't exist in > tree. Its for the repo on github. I'm not planning on pushing that. > VEX changes OK, except for unnecessarily extending VexGuestARM64State for > non-freebsd systems. > Would be really nice if that VEX/auxprogs/genoffsets.c > GENOFFSET(ARM64,arm64,SETC); could only > be done of freebsd. I don't think it's too much a big deal - there's only one VexGuestARM64State per thread. > > coregrind/m_coredump/coredump-elf.c looks correct (do we have any tests for > this? I don't believe we do). FreeBSD needs to have its own core dump routines - as I understand it each OS uses a different layout. Nobody has asked me to fix it yet. It builds and it dumps a core file. > coregrind/m_debuglog.c dunno why there is a clang and gcc variant of > local_sys_write_stderr. One uses SizeT the other Unt (should be Int). I used two version, the Linux and one from the out of tree Darwin port. Both only work with one compiler. I'll leave it for now and add it to my todo list. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481676] Build failure on Raspberry Pi 5 Ubuntu 23.10 with clang
https://bugs.kde.org/show_bug.cgi?id=481676 Paul Floyd changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Paul Floyd --- commit 33091a1c4410c4641a8ffd219a1c0b1f42120780 (HEAD -> master, origin/master, origin/HEAD) Author: Paul Floyd Date: Mon Apr 15 07:03:23 2024 +0200 Add Bug 481676 to NEWS Forgot I'd opened a bugzi for the problem. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485148] vfmadd213ss instruction is instrumented incorrectly (the remaining part of the register is cleared instead of kept unmodified)
https://bugs.kde.org/show_bug.cgi?id=485148 Paul Floyd changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #16 from Paul Floyd --- commit 219998aeb64e28391861006e9eb1ea4b96d69083 (HEAD -> master, origin/users/paulf/try-bug485148, origin/master, origin/HEAD, bug485148) Author: Paul Floyd Date: Sun Apr 14 17:59:30 2024 +0200 Bug 485148 - vfmadd213ss instruction is instrumented incorrectly (the remaining part of the register is cleared instead of kept unmodified) Initial version contributed by Bruno Lathuilire Initial test contributed by Petr -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485148] vfmadd213ss instruction is instrumented incorrectly (the remaining part of the register is cleared instead of kept unmodified)
https://bugs.kde.org/show_bug.cgi?id=485148 --- Comment #15 from Paul Floyd --- Can you share any of those tests? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481127] [PATCH] amd64: Implement VFMADD213 for Iop_MAddF32
https://bugs.kde.org/show_bug.cgi?id=481127 --- Comment #11 from Paul Floyd --- For the attribution I would just put Patch contributed by Gražvydas Ignotas and Bruno Lathuilière (with the right accents if possible) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481874] Add arm64 support for FreeBSD
https://bugs.kde.org/show_bug.cgi?id=481874 Paul Floyd changed: What|Removed |Added Attachment #167199|0 |1 is obsolete|| --- Comment #16 from Paul Floyd --- Created attachment 168432 --> https://bugs.kde.org/attachment.cgi?id=168432=edit slimmed down patch I've updated the 'none' testcases from Linux arm64 which makes the patch a lot smaller. The big bits are now the scalar expected and the new files. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485400] io_uring filled memory not marked as defined
https://bugs.kde.org/show_bug.cgi?id=485400 --- Comment #1 from Paul Floyd --- > My hunch is that valgrind doesn't know to mark buffers filled by io_uring as > defined. I prefer to understand the code and use a debugger to see what is actually happening. > Valgrind has a false-positive complaint that the returned read buffer has > uninitialized data. Wow. It's Rust, it must be right, is that it? Strangely I'm not too motivated to investigate this. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 476025] Vbit expected test results for Iop_CmpGT64Ux2 are wrong.
https://bugs.kde.org/show_bug.cgi?id=476025 Paul Floyd changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 476025] Vbit expected test results for Iop_CmpGT64Ux2 are wrong.
https://bugs.kde.org/show_bug.cgi?id=476025 --- Comment #13 from Paul Floyd --- Merged commit 94e826519a810e52bba539a7c41f4074f0631e10 (HEAD -> master, origin/master, origin/HEAD) Author: Eyal Soha Date: Tue Oct 24 21:52:56 2023 -0600 Add support for expensive cmpgt into vbits -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 476025] Vbit expected test results for Iop_CmpGT64Ux2 are wrong.
https://bugs.kde.org/show_bug.cgi?id=476025 Paul Floyd changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 335875] WARNING: unhandled syscall: 270
https://bugs.kde.org/show_bug.cgi?id=335875 Paul Floyd changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED CC||pjfl...@wanadoo.fr --- Comment #1 from Paul Floyd --- Looks like this got fixed ages ago. commit b96092d5dff6e87b56afb07c331c70dec723f462 Author: Julian Seward , Wed Oct 15 15:57:11 2014 + (9 years ago) Committer: Julian Seward , Wed Oct 15 15:57:11 2014 + (9 years ago) Enable sys_fadvise64_64 on arm32. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 476025] Vbit expected test results for Iop_CmpGT64Ux2 are wrong.
https://bugs.kde.org/show_bug.cgi?id=476025 Paul Floyd changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Paul Floyd --- I think that these have all been merged. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444431] Incorrectly assumes static text is uninitialized
https://bugs.kde.org/show_bug.cgi?id=31 Paul Floyd changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG CC||pjfl...@wanadoo.fr --- Comment #8 from Paul Floyd --- You code is truly horrible. gotos everywhere. Including C source in the middle of a file. K non-prototype function declarations. The Makefile looks like it is trying to be a script. The Makefile mixes compiler flags and linker flags willy nilly. You really need to learn how to program correctly. The first error is on this line │ > 144 val = (arg[1][argl[1] - 1] == '$') ? defaultstr : defaultnu│ arg is char **arg = NULL; and argl is int32_t *argl = NULL; The seem to be allocated OK. arg[1] contains "TEST". argl[1] contains 6. Than means you are accessing the 6-1 = 5 or the 6th byte in arg[1]. But it only points to 5 bytes. There are lots of bugs in the code. For a start I think that argl[i] = ngptr - gptr; is out by one and should be argl[i] = ngptr - gptr - 1; -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 449417] "Remote server misconfigured" when trying to send email to valgr...@valgrind.org
https://bugs.kde.org/show_bug.cgi?id=449417 Paul Floyd changed: What|Removed |Added Status|REPORTED|RESOLVED CC||pjfl...@wanadoo.fr Resolution|--- |FIXED --- Comment #1 from Paul Floyd --- The e-mail address should now work, and get redirected to a group of core developers. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 397083] Likely false positive "uninitialised value(s)" for __wmemchr_avx2 and __wmemcmp_avx2_movbe
https://bugs.kde.org/show_bug.cgi?id=397083 Paul Floyd changed: What|Removed |Added CC||takimot...@kba.biglobe.ne.j ||p --- Comment #16 from Paul Floyd --- *** Bug 452072 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452072] false positive from wmemcmp_avx2_movbe (glibc-2.34 or later?)
https://bugs.kde.org/show_bug.cgi?id=452072 Paul Floyd changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE CC||pjfl...@wanadoo.fr --- Comment #1 from Paul Floyd --- *** This bug has been marked as a duplicate of bug 397083 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485276] std::optional use: "Conditional jump or move depends on uninitialised value(s)" (clang) aarch64
https://bugs.kde.org/show_bug.cgi?id=485276 --- Comment #2 from Paul Floyd --- With debuginfo it might be OK to suppress this. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485276] std::optional use: "Conditional jump or move depends on uninitialised value(s)" (clang) aarch64
https://bugs.kde.org/show_bug.cgi?id=485276 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485148] vfmadd213ss instruction is instrumented incorrectly (the remaining part of the register is cleared instead of kept unmodified)
https://bugs.kde.org/show_bug.cgi?id=485148
--- Comment #11 from Paul Floyd ---
Maybe this then
--- a/VEX/priv/guest_amd64_toIR.c
+++ b/VEX/priv/guest_amd64_toIR.c
@@ -27987,10 +27987,9 @@ static Long dis_FMA ( const VexAbiInfo* vbi, Prefix
pfx, Long delta, UChar opc )
for (i = 0; i < count; i++) {
putYMMRegLane(rG, i, res[i]);
}
-
switch (vty) {
- case Ity_F32: putYMMRegLane32(rG, 1, mkU32(0)); /*fallthru*/
- case Ity_F64: putYMMRegLane64(rG, 1, mkU64(0)); /*fallthru*/
+ case Ity_F32:
+ case Ity_F64:
case Ity_V128: putYMMRegLane128(rG, 1, mkV128(0)); /*fallthru*/
case Ity_V256: break;
default: vassert(0);
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 485134] [PATCH] vgcore files unusable in gdb / does not load debug symbols
https://bugs.kde.org/show_bug.cgi?id=485134 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr Summary|vgcore files unusable in|[PATCH] vgcore files |gdb / does not load debug |unusable in gdb / does not |symbols |load debug symbols -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481874] Add arm64 support for FreeBSD
https://bugs.kde.org/show_bug.cgi?id=481874 --- Comment #15 from Paul Floyd --- The last two files with big diffs are none/tests/arm64/integer.c (clang moaned about integer conversions so I added LL suffixes and also clang was strict about only accepting 32bit w registers where gcc accepts x registers). The expected reflects the change from x to w. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481874] Add arm64 support for FreeBSD
https://bugs.kde.org/show_bug.cgi?id=481874 --- Comment #14 from Paul Floyd --- The diffs for the new none expecteds (compared to the originals) are fairly small diff none/tests/arm64/fp_and_simd.stdout.exp-freebsd none/tests/arm64/fp_and_simd.stdout.exp 44c44 < special value 7 = nan --- > special value 7 = -nan I could add a filter instead of the expected. iff none/tests/arm64/memory_test.stdout.exp none/tests/arm64/memory_test.stdout.exp-clang 7582c7582 < 76e0f98045156b32 v17.d[0] (xor, xfer vecreg #1) --- > 76e0f98045156a32 v17.d[0] (xor, xfer vecreg #1) 7612c7612 < 07cfd3de4a8087e3 v17.d[0] (xor, xfer vecreg #1) --- > 07cfd2de4a8086e3 v17.d[0] (xor, xfer vecreg #1) 7642,7643c7642,7643 < 04a3c72e55e713a0 v17.d[0] (xor, xfer vecreg #1) < 67bbbee861cf4eb2 v17.d[1] (xor, xfer vecreg #1) --- > 04a3c62e55e712a0 v17.d[0] (xor, xfer vecreg #1) > 67bbbfe861cf4fb2 v17.d[1] (xor, xfer vecreg #1) That would be a bit trickier to filter. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481874] Add arm64 support for FreeBSD
https://bugs.kde.org/show_bug.cgi?id=481874 --- Comment #13 from Paul Floyd --- Created attachment 168313 --> https://bugs.kde.org/attachment.cgi?id=168313=edit Added except large none test references git diff master --diff-filter=A ':(exclude)none/tests/arm64/fp_and_simd.stdout.exp-freebsd' ':(exclude)none/tests/arm64/memory_test.stdout.exp-clang' > added1.diff -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481874] Add arm64 support for FreeBSD
https://bugs.kde.org/show_bug.cgi?id=481874 --- Comment #12 from Paul Floyd --- Created attachment 168311 --> https://bugs.kde.org/attachment.cgi?id=168311=edit Modified except large none test files git diff master --diff-filter=M ':(exclude)none/tests/arm64/integer.c' ':(exclude)none/tests/arm64/integer.stdout.exp' > modified1.diff -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481874] Add arm64 support for FreeBSD
https://bugs.kde.org/show_bug.cgi?id=481874 --- Comment #11 from Paul Floyd --- (In reply to Mark Wielaard from comment #9) > In VEX. What are the priv/guest_arm64_toIR.c changes for? Just some whitespace diffs. I've restored them. > Would it make sense to only include those fields, and padding, for freebsd? Yes but that won't work with genoffsets which doesn't support conditional compilation. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481874] Add arm64 support for FreeBSD
https://bugs.kde.org/show_bug.cgi?id=481874 --- Comment #10 from Paul Floyd --- (In reply to Mark Wielaard from comment #9) > You need LibVEX_GuestARM64_put_nzcv_c to signal syscall success/failure. > I am not fully clear what the guest_SETC is for. If there is an asynchronous interrupt during a guest syscall we need to figure out where to restart the syscall. On Linux that is fairly straightforward. The assembler for ML_(do_syscall_for_client_WRK) has markers for the various stages and we just compare the PC to those markers. On FreeBSD and macOS things are different because of the carry flag for the syscall status. That gets set by a function call. So if the interrupt happens in the function call (LibVEX_GuestARM64_put_nzcv_c) the PC is no good. We can reliably know the address of the start of the function, but that's all. In this case there are also several helper functions. A while back I was using a hack by putting a dummy function after the 'set carry' function. That doesn't work on ARM64 so I switched to using a flag. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485148] vfmadd213ss instruction is instrumented incorrectly (the remaining part of the register is cleared instead of kept unmodified)
https://bugs.kde.org/show_bug.cgi?id=485148 --- Comment #7 from Paul Floyd --- I wanted to make sure that it is only a problem with vfmadd132ss . -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 485148] vfmadd213ss instruction is instrumented incorrectly (the remaining part of the register is cleared instead of kept unmodified)
https://bugs.kde.org/show_bug.cgi?id=485148
--- Comment #5 from Paul Floyd ---
If anything, I prefer C++.
For reference, here it is in godbolt https://godbolt.org/z/bM5brqWM6
And here is what I see in gdb with vgdb before and after single stepping the
vfmadd132ss instruction
(gdb) p $xmm0
$1 = {v4_float = {1, 2, 3, 4}, v2_double = {2.004731118679,
512.00012254714966}, v16_int8 = {0, 0, -128, 63, 0, 0, 0, 64, 0, 0, 64, 64, 0,
0, -128, 64}, v8_int16 = {0, 16256, 0, 16384, 0, 16448, 0, 16512}, v4_int32 =
{1065353216, 1073741824,
1077936128, 1082130432}, v2_int64 = {4611686019492741120,
4647714816524288000}, uint128 = 85735205748011485687928662073142149120}
(gdb) p $xmm1
$2 = {v4_float = {-1, -2, -19, 0}, v2_double = {-2.014267861843,
1.6047075103796218e-314}, v16_int8 = {0, 0, -128, -65, 0, 0, 0, -64, 0, 0,
-104, -63, 0, 0, 0, 0}, v8_int16 = {0, -16512, 0, -16384, 0, -15976, 0, 0},
v4_int32 = {-1082130432,
-1073741824, -1047003136, 0}, v2_int64 = {-4611686015214551040,
3247964160}, uint128 = 59914363633936079956933083136}
(gdb) p $xmm2
$3 = {v4_float = {3, 11, 35, 1}, v2_double = {1048576.2509765625,
0.0078125019222170522}, v16_int8 = {0, 0, 64, 64, 0, 0, 48, 65, 0, 0, 12, 66,
0, 0, -128, 63}, v8_int16 = {0, 16448, 0, 16688, 0, 16908, 0, 16256}, v4_int32
= {1077936128, 1093664768,
1108082688, 1065353216}, v2_int64 = {4697254412425363456,
4575657222516506624}, uint128 = 84405977752782675692133152826159267840}
(gdb) si
(gdb) p $xmm0
$4 = {v4_float = {2, 0, 0, 0}, v2_double = {5.3049894774131808e-315, 0},
v16_int8 = {0, 0, 0, 64, 0 }, v8_int16 = {0, 16384, 0, 0, 0,
0, 0, 0}, v4_int32 = {1073741824, 0, 0, 0}, v2_int64 = {1073741824, 0}, uint128
= 1073741824}
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 485148] vfmadd213ss instruction is instrumented incorrectly (the remaining part of the register is cleared instead of kept unmodified)
https://bugs.kde.org/show_bug.cgi?id=485148 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr --- Comment #2 from Paul Floyd --- Can you share a testcase? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484935] [patch] Valgrind reports false "Conditional jump or move depends on uninitialised value" errors for aarch64 signal handlers
https://bugs.kde.org/show_bug.cgi?id=484935 --- Comment #6 from Paul Floyd --- (In reply to Peter Edwards from comment #5) > Thanks for the fast turn-around! You're welcome. It helps that I'd already done the same. I wish that more issues here coule be so easy. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484935] [patch] Valgrind reports false "Conditional jump or move depends on uninitialised value" errors for aarch64 signal handlers
https://bugs.kde.org/show_bug.cgi?id=484935 Paul Floyd changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Paul Floyd --- Change and slightly modified test pushed. Thanks! commit 97854e557ebc5df690103808a45fa282d5adfd96 (HEAD -> master, origin/master, origin/HEAD) Author: Paul Floyd Date: Wed Apr 3 08:32:12 2024 +0200 Bug 484935 - [patch] Valgrind reports false "Conditional jump or move depends on uninitialised value" errors for aarch64 signal handlers Patch contributed by Peter Edwards Testcase modified and added to a new directory, memcheck/tests/arm64 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484935] [patch] Valgrind reports false "Conditional jump or move depends on uninitialised value" errors for aarch64 signal handlers
https://bugs.kde.org/show_bug.cgi?id=484935 --- Comment #3 from Paul Floyd --- I'll need to make a few changes to the testcase (so that it compiles on FreeBSD and doesn't have an infinite loop). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484935] [patch] Valgrind reports false "Conditional jump or move depends on uninitialised value" errors for aarch64 signal handlers
https://bugs.kde.org/show_bug.cgi?id=484935 --- Comment #2 from Paul Floyd --- I fully agree with this. I've done a port to FreeBSD arm64 and I did exactly the same thing https://github.com/paulfloyd/freebsdarm64_valgrind/commit/d6d97cb954ef10c66ee117f536f92659dcbacf65 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484935] [patch] Valgrind reports false "Conditional jump or move depends on uninitialised value" errors for aarch64 signal handlers
https://bugs.kde.org/show_bug.cgi?id=484935 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr Assignee|jsew...@acm.org |pjfl...@wanadoo.fr -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450203] unhandled instruction 0xD5380015 [ARM64]
https://bugs.kde.org/show_bug.cgi?id=450203 Paul Floyd changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #1 from Paul Floyd --- I believe that this is 0x1: D5 38 00 15mrsx21, midr_el1 So this bug report is a duplicate of 392146. *** This bug has been marked as a duplicate of bug 392146 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 392146] aarch64: unhandled instruction 0xD5380001 (MRS rT, mdir_el1)
https://bugs.kde.org/show_bug.cgi?id=392146 Paul Floyd changed: What|Removed |Added CC||jonathan.girardeau@airudit. ||com --- Comment #19 from Paul Floyd --- *** Bug 450203 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450203] unhandled instruction 0xD5380015 [ARM64]
https://bugs.kde.org/show_bug.cgi?id=450203 Paul Floyd changed: What|Removed |Added Summary|unhandled instruction |unhandled instruction |0xD5380015 [ARM]|0xD5380015 [ARM64] -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 460616] disInstr(arm64): unhandled instruction 0x4E819402 (dotprod/ASIMDDP)
https://bugs.kde.org/show_bug.cgi?id=460616 Paul Floyd changed: What|Removed |Added CC||joost.vandevond...@gmail.co ||m --- Comment #7 from Paul Floyd --- *** Bug 484742 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484742] unhandled instruction 0x4E9096B7
https://bugs.kde.org/show_bug.cgi?id=484742 Paul Floyd changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Paul Floyd --- OK on ubuntu Raspberry Pi 5 I get info string NNUE evaluation using nn-1ceb1ade0001.nnue info string NNUE evaluation using nn-baff1ede1f90.nnue disInstr(arm64): unhandled instruction 0x4E9196DF disInstr(arm64): 0100'1110 1001'0001 1001'0110 1101' ==51681== valgrind: Unrecognised instruction at address 0x118f6c. ==51681==at 0x118F6C: Stockfish::Eval::NNUE::Network, Stockfish::Eval::NNUE::FeatureTransformer<2560u, ::StateInfo::accumulatorBig> >::evaluate(Stockfish::Position const&, bool, int*, bool) const [clone .constprop.0] (in /home/paulf/scratch/Stockfish/src/stockfish) with ubuntu's Valgrind 3.21 NS1_19NetworkArchitectureILj2560ELi15ELi32EEENS1_18FeatureTransformerILj2560EXadL_ZNS_9StateInfo14accumulatorBigEE8evaluateERKNS_8PositionEbPib.constprop.0+3692> sdotv31.4s, v22.16b, v17.16b But no problem with Valgrind built from source. Looks like this was fixed with Author: William Ashley 2023-11-10 17:51:12 Committer: Mark Wielaard 2023-11-10 17:55:22 Parent: aa3432229dff78dbbe95aeb0604215d3d588c4a4 (regtest: bug401284.c should never cast the return of malloc in C) Child: 242d8881e10328ff98c37ceb7fd31955a29cad82 (Bug 476787 - Build of Valgrind 3.21.0 fails when SOLARIS_PT_SUNDWTRACE_THRP is defined) Branches: master, remotes/origin/master, remotes/origin/users/paulf/try-bug484480, remotes/origin/users/paulf/try-carry, remotes/origin/users/paulf/try-sem_clockwait_np Follows: VALGRIND_3_22_0 Precedes: Bug 460616 - Add support for aarch64 dotprod instructions This change adds support for the FEAT_DotProd instructions SDOT ., ., .4B[] SDOT ., ., . UDOT ., ., .4B[] UDOT ., ., . Please build your own Valgrind from source, or wait for Valgrind 3.23 which is duu out sometime this month (April 2024). *** This bug has been marked as a duplicate of bug 460616 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 392146] aarch64: unhandled instruction 0xD5380001 (MRS rT, mdir_el1)
https://bugs.kde.org/show_bug.cgi?id=392146 --- Comment #18 from Paul Floyd --- (In reply to Peter Maydell from comment #17) > The Linux kernel documents which ID registers and which fields in those > registers it exposes here: > https://www.kernel.org/doc/Documentation/arm64/cpu-feature-registers.txt . > Does FreeBSD expose the same set, or a different set? I don't know of any such document. I expect that they are similar since FreeBSD has a linux compatibility layer and it sets possibly different HWCAPs for FreeBSD apps and for Linux apps running under the compat layer. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484742] unhandled instruction 0x4E9096B7
https://bugs.kde.org/show_bug.cgi?id=484742 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr --- Comment #3 from Paul Floyd --- I tried on FreeBSD but couldn't get stockfish to build I'll give it a go on ubuntu next time I boot it. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 392146] aarch64: unhandled instruction 0xD5380001 (MRS rT, mdir_el1)
https://bugs.kde.org/show_bug.cgi?id=392146 --- Comment #16 from Paul Floyd --- And the patch seems to work, with the patch FF proceeds until it hits a SIGBUS (which is what I was looking for). I'll look at it in more detail. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 392146] aarch64: unhandled instruction 0xD5380001 (MRS rT, mdir_el1)
https://bugs.kde.org/show_bug.cgi?id=392146 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr Assignee|jsew...@acm.org |pjfl...@wanadoo.fr --- Comment #15 from Paul Floyd --- Well it's time for me to look at this again. I just tried to run Firefox on FreeBSD under Valgrind and I got ARM64 front end: branch_etc disInstr(arm64): unhandled instruction 0xD5380609 disInstr(arm64): 1101'0101 0011'1000 '0110 '1001 ==2219== valgrind: Unrecognised instruction at address 0xdfa7880. ==2219==at 0xDFA7880: SkCpu::CacheRuntimeFeatures() (in /usr/local/lib/firefox/libxul.so) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 377966] Error message said to report
https://bugs.kde.org/show_bug.cgi?id=377966 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr Assignee|assad.has...@linaro.org |pjfl...@wanadoo.fr -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484480] False positives when using sem_trywait
https://bugs.kde.org/show_bug.cgi?id=484480 Paul Floyd changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Paul Floyd --- commit 485cea48a38db8db608bdaff0c695ff50bbe16b5 (HEAD -> master, origin/users/paulf/try-bug484480, origin/master, origin/HEAD, bug484480) Author: Paul Floyd Date: Sat Mar 30 16:31:12 2024 +0100 Bug 484480 - False positives when using sem_trywait -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484480] False positives when using sem_trywait
https://bugs.kde.org/show_bug.cgi?id=484480
Paul Floyd changed:
What|Removed |Added
Assignee|jsew...@acm.org |pjfl...@wanadoo.fr
--- Comment #3 from Paul Floyd ---
Comment in hg_intercepts.c
Unhandled:
int sem_trywait(sem_t *sem);
int sem_timedwait(sem_t *restrict sem,
const struct timespec *restrict abs_timeout);
I looked at DRD, it just does the same thing as sem_wait so I tried this code
on FreeBSD
__attribute__((noinline))
static int sem_trywait_WRK(sem_t* sem)
{
OrigFn fn;
intret;
VALGRIND_GET_ORIG_FN(fn);
if (TRACE_SEM_FNS) {
fprintf(stderr, "<< sem_trywait(%p) ", sem);
fflush(stderr);
}
DO_CREQ_v_W(_VG_USERREQ__HG_POSIX_SEM_WAIT_PRE, sem_t*,sem);
CALL_FN_W_W(ret, fn, sem);
DO_CREQ_v_WW(_VG_USERREQ__HG_POSIX_SEM_WAIT_POST, sem_t*,sem,
long, (ret == 0) ? True : False);
if (ret != 0) {
DO_PthAPIerror( "sem_trywait", SEM_ERROR );
}
if (TRACE_SEM_FNS) {
fprintf(stderr, " sem_trywait -> %d >>\n", ret);
fflush(stderr);
}
return ret;
}
#if defined(VGO_freebsd)
LIBC_FUNC(int, semZutrywait, sem_t* sem) { /* sem_trywait */
return sem_trywait_WRK(sem);
}
#endif
and it seems to work.
I'll clean the code up (and add sem_timedwait) sometime this weekend.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 484426] aarch64: 0.5 gets rounded to 0
https://bugs.kde.org/show_bug.cgi?id=484426 Paul Floyd changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #8 from Paul Floyd --- commit dc30fbf673953fefb115d2cf441119ee28039c9c (HEAD -> master, origin/master, origin/HEAD) Author: Paul Floyd Date: Thu Mar 28 20:55:38 2024 +0100 Bug 484426 - aarch64: 0.5 gets rounded to 0 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484426] aarch64: 0.5 gets rounded to 0
https://bugs.kde.org/show_bug.cgi?id=484426 --- Comment #7 from Paul Floyd --- (In reply to Mark Wielaard from comment #6) > This looks good to me. But I have not tested it. And I have to trust you on > the emit code (too lazy to look up the instr enc) > > It looks like none/tests/arm64/fp_and_simd.c already has tests for both > frinti and frinta. > Did they just happen to work just fine with the existing code? I haven't looked at the testcase to see exactly what values they are using. frinta only affects floating point values that are "integer.5". frintn only affects the result for "odd integer.5" values. So I guess that the testcase doesn't use "point five" values. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484002] Add suppression for invalid read in glibc's __wcpncpy_avx2() via wcsxfrm()
https://bugs.kde.org/show_bug.cgi?id=484002 Paul Floyd changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484002] Add suppression for invalid read in glibc's __wcpncpy_avx2() via wcsxfrm()
https://bugs.kde.org/show_bug.cgi?id=484002 --- Comment #8 from Paul Floyd --- Haven't heard any complaints so closing this. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484426] aarch64: 0.5 gets rounded to 0
https://bugs.kde.org/show_bug.cgi?id=484426 --- Comment #5 from Paul Floyd --- The patch doesn't cover the vector versions. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484426] aarch64: 0.5 gets rounded to 0
https://bugs.kde.org/show_bug.cgi?id=484426 --- Comment #4 from Paul Floyd --- Created attachment 167836 --> https://bugs.kde.org/attachment.cgi?id=167836=edit Patch adding new Iops Dunno why arm64 didn't add more FPCR rounding modes. Probably because of historical baggage from am32 where a) there are only 32 bits and b) fpcsr does the job of both control fpcr and status fpsr. Anyway, this seems to work. Developed on FreeBSD but it should work OK on Linux. Small bonus: frinta and frintn now generate unops and don't pfaff around with the rounding mode. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484426] aarch64: 0.5 gets rounded to 0
https://bugs.kde.org/show_bug.cgi?id=484426 Paul Floyd changed: What|Removed |Added Assignee|jsew...@acm.org |pjfl...@wanadoo.fr -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484426] aarch64: 0.5 gets rounded to 0
https://bugs.kde.org/show_bug.cgi?id=484426 --- Comment #3 from Paul Floyd --- I think that I understand the problem. arm64 has two overlapping ways of doing floating point rounding. The mnemonics are FRINT (Float Round to Int) and then one more letter for the kind of rounding. The FPCR (Floating Point Control Register) has 2 bits for the rounding mode (00 nearest 01 towards +inf 10 towards -inf 11 towards zero) I - use the current rounding mode P - like rounding mode 01 M - like rounding mode 10 Z - like rounding mode 11 but then there is N - to nearest, ties to even A - to nearest, ties away from zero X - exact, like I but causes inexect FPE or sets IneXact Computing bit in FPSR Out problem is that we're trying to use FRINTI for everything in the generated code. That's not too bad for FRINTX (we don't support FPEs). But it's wrong for N and A. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484480] False positives when using sem_trywait
https://bugs.kde.org/show_bug.cgi?id=484480 Paul Floyd changed: What|Removed |Added Resolution|--- |NOT A BUG Status|REPORTED|RESOLVED --- Comment #1 from Paul Floyd --- If I add a pthread_join then I get no error. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484480] False positives when using sem_trywait
https://bugs.kde.org/show_bug.cgi?id=484480 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 281975] Memcheck crashes on the Cortex A9 Armv7 processor executing unsupported VMD instructions
https://bugs.kde.org/show_bug.cgi?id=281975 --- Comment #9 from Paul Floyd --- I had a look at other platforms and PPC does something similar to handle older and newer hardware. So perhaps it's not so bad. I'll try to run the perf suite to compare with and without (on an RPi 5). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484426] aarch64: 0.5 gets rounded to 0
https://bugs.kde.org/show_bug.cgi?id=484426
--- Comment #2 from Paul Floyd ---
Comment from code:
* FRINTA, FRINTN are kludged .. they just round to nearest. No special
handling for the "ties" case. FRINTX might be dubious too.
* Ditto FCVTXN. No idea what "round to odd" means. This implementation
just rounds to nearest.
"round to odd" does what the name says and rounds to odd integers. It's one of
several rounding methods with the advantage that (like round to even) there is
no bias, half of ties round up ("even point 5") and half round down ("odd point
five"). So 0.5 rounds to 1.0.
https://developer.arm.com/documentation/dui0801/g/A64-Floating-point-Instructions/FCVT?lang=en
says that depends on the FPCR
gdb says
fpcr 0x0 [ Len=0 Stride=0 RMode=0 ]
RMode 0 means round to zero, which is probably just about the only thing ever
used.
For float to double there should be no rounding (which I guess only applies to
the ULP for floating point conversions).
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 484426] aarch64: 0.5 gets rounded to 0
https://bugs.kde.org/show_bug.cgi?id=484426
Paul Floyd changed:
What|Removed |Added
CC||pjfl...@wanadoo.fr
--- Comment #1 from Paul Floyd ---
I get the same with clang++17, FreeBSD 14 on an RPi 5.
The code compiles to a call to __builtin_round
│0x211820 <_Z5roundB7v160006f+12>
fcvtd0, s0
│0x211824 <_Z5roundB7v160006f+16>
frinta d0, d0
│0x211828 <_Z5roundB7v160006f+20>
fcvts0, d0
I think that means
convert float to double
round to int
convert double to float
Loaded into s0 I see
(gdb) p $s0
$4 = {f = 0.5, u = 1056964608, s = 1056964608}
(gdb) p /x $s0
$5 = {f = 0x3f00, u = 0x3f00, s = 0x3f00}
After conversion to double
(gdb) p $d0
$8 = {f = 5.2220990168285998e-315, u = 1056964608, s = 1056964608}
(gdb) p /x $d0
$9 = {f = 0x3f00, u = 0x3f00, s = 0x3f00}
Looks wrong
After the rounding
(gdb) p $d0
$10 = {f = 0, u = 0, s = 0}
And convert back to float
(gdb) p $s0
$12 = {f = 0, u = 0, s = 0}
Now, if I fix $d0 in gdb I get
(gdb) set $d0=0.5
(gdb) p $d0
$14 = {f = 0.5, u = 4602678819172646912, s = 4602678819172646912}
(gdb) p /x $d0
$15 = {f = 0x3fe0, u = 0x3fe0, s = 0x3fe0}
but that still rounds down to zero.
If I comple a double version, the __builtin_round becomes just a frinta, the
value for $d0 is the same as when I set it in gdb and it still rounds down to
0.0.
So I see two problems, the first with fcvt and the second with frinta.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 474160] If errors-for-leak-kinds is specified, exit-on-first-error should only exit on one of the listed errors.
https://bugs.kde.org/show_bug.cgi?id=474160 Paul Floyd changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #4 from Paul Floyd --- Thanks! Added to NEWS and changed commit message commit ca58f30a5e728cda2802c7fafdc0770a45a5f8cb (HEAD -> master, origin/master, origin/HEAD) Author: Eyal Soha Date: Tue Mar 2 14:42:38 2021 -0700 Bug 474160 - If errors-for-leak-kinds is specified, exit-on-first-error should only exit on one of the listed errors. It's possible for the user to specify in the memcheck that some errors should not cause an exit with the error-exitcode value. For those errors which would not cause an error exitcode, do not count them for the purposes of exiting after the first error. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 398569] invalid reads reported in libarmmem memcmp when using strings
https://bugs.kde.org/show_bug.cgi?id=398569 --- Comment #8 from Paul Floyd --- And the pull request has been merged. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 281975] Memcheck crashes on the Cortex A9 Armv7 processor executing unsupported VMD instructions
https://bugs.kde.org/show_bug.cgi?id=281975 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr --- Comment #4 from Paul Floyd --- Wouldn't it be better to do this check at compile time? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484002] Add suppression for invalid read in glibc's __wcpncpy_avx2() via wcsxfrm()
https://bugs.kde.org/show_bug.cgi?id=484002 --- Comment #7 from Paul Floyd --- I just pushed a fix. Could you confirm that it is OK? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452387] valgrind: m_debuginfo/readelf.c:717 (get_elf_symbol_info): Assertion 'in_rx' failed. [ARMV7]
https://bugs.kde.org/show_bug.cgi?id=452387 --- Comment #8 from Paul Floyd --- I don't know all of the details of this, but memcheck has a requirement in the link loader (ld-xxx.so) that it contain two visible functions, index and strlen (and a few others depending on the platform). If these functions don't get redirected then the result can be large numbers of false positive errors. I think that the real problem is that there is no way for us to distinguish between a ld-xxx.so that does not contain 'index' and one that does but is stripped and we can't see it. If you can rebuild Valgrind you could try commenting out add_hardwired_spec( "ld-linux-armhf.so.3", "index", (Addr)_(arm_linux_REDIR_FOR_index), complain_about_stripped_glibc_ldso ); in m_redir.c in the VGP_arm_linux block of VG_(redir_initialise) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484002] Add suppression for invalid read in glibc's __wcpncpy_avx2() via wcsxfrm()
https://bugs.kde.org/show_bug.cgi?id=484002 --- Comment #6 from Paul Floyd --- I saw the "wcspcpy" as well. The +4 was a copy and paste, there are a few wide character functions with +4 and also some with *4. The testcase needs improving - printing the addresses of the stack and heap variables isn't much use. Also FreeBSD wcsxfrm doesn't use wcpncpy so I'd like a test directly using wcpncpy. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484002] Add suppression for invalid read in glibc's __wcpncpy_avx2() via wcsxfrm()
https://bugs.kde.org/show_bug.cgi?id=484002 --- Comment #4 from Paul Floyd --- Created attachment 167483 --> https://bugs.kde.org/attachment.cgi?id=167483=edit first attempt at a patch I don't think I have access to a machine with F29 and avx2. Could you try this please? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484002] Add suppression for invalid read in glibc's __wcpncpy_avx2() via wcsxfrm()
https://bugs.kde.org/show_bug.cgi?id=484002 --- Comment #3 from Paul Floyd --- (In reply to Mark Wielaard from comment #2) > We already have an override for wcsncpy and stpncpy. But not wcpncpy. > See shared/vg_replace_strmem.c Yes I think that this should be virtually the same as wcsncpy with only the return value being different. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 484002] Add suppression for invalid read in glibc's __wcpncpy_avx2() via wcsxfrm()
https://bugs.kde.org/show_bug.cgi?id=484002 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr Assignee|jsew...@acm.org |pjfl...@wanadoo.fr --- Comment #1 from Paul Floyd --- This needs a redirect, not a suppression. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 472346] False positive mismatched frees
https://bugs.kde.org/show_bug.cgi?id=472346 Paul Floyd changed: What|Removed |Added Resolution|--- |NOT A BUG Status|REPORTED|RESOLVED --- Comment #2 from Paul Floyd --- Not too surprisingly, the second problem is also a user error. There's a 3rd party library that links stitically with libstdc++ using a linker script to give all sumbols local scope except for a few global symbols in the exported interface. Then there is a header with inline functions that call new and delete. The new gets called from the context of the 3rd party lib and so uses the hidden static libstdc++ new. The delete gets called from the context of the main exe an uses dynamic libstdc++ which isn't hidden. So memcheck sees a 'malloc' for the allocation and a 'delete' for the deallocation, and complains. The static new can be seen from the debuginfo but it doesn't get redirected. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 452387] valgrind: m_debuginfo/readelf.c:717 (get_elf_symbol_info): Assertion 'in_rx' failed. [ARMV7]
https://bugs.kde.org/show_bug.cgi?id=452387 --- Comment #6 from Paul Floyd --- It is hitting an assert when reading ld-2.15.so The program headers say that this only has 312 bytes of executable code PT_LOAD[1]: p_offset 0, p_filesz 312, perms r-x then it tris to look at _dl_start raw symbol [ 32]: LOC FUN : svma 0x0039d5, sz 1296 _dl_start which is 1296 bytes. Can you tell us why you are using ld-2.15.so in /tmp instead of somewhere more 'standard' like /lib or /usr/lib? And can you tell us if this is a copy of the system ld-2.15.so which I assume will be in one of those directories? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 472346] False positive mismatched frees
https://bugs.kde.org/show_bug.cgi?id=472346 --- Comment #1 from Paul Floyd --- For the second exe, the problem is with tcmalloc. As an optimization it just uses a single function for free and operator deletes. See the comments here https://github.com/gperftools/gperftools/issues/792. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 463463] none/tests/amd64/fma fails when executed under valgrind on a x86-64-v3 system
https://bugs.kde.org/show_bug.cgi?id=463463 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481127] [PATCH] amd64: Implement VFMADD213 for Iop_MAddF32
https://bugs.kde.org/show_bug.cgi?id=481127 --- Comment #5 from Paul Floyd --- Should we also support F16? Does this also work with the other permutatons 132 and 231? Lastly, do packed and scalar make any difference? This will need a regression test as well. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 392146] aarch64: unhandled instruction 0xD5380001 (MRS rT, mdir_el1)
https://bugs.kde.org/show_bug.cgi?id=392146 --- Comment #13 from Paul Floyd --- Do you have any tests for this? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 482013] Unhandled instruction 0xD5380008 on arm64 platform (mrs x8, midr_el1)
https://bugs.kde.org/show_bug.cgi?id=482013 Paul Floyd changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #2 from Paul Floyd --- I see there was an earlier report of this, with a patch. *** This bug has been marked as a duplicate of bug 392146 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 392146] aarch64: unhandled instruction 0xD5380001 (MRS rT, mdir_el1)
https://bugs.kde.org/show_bug.cgi?id=392146 Paul Floyd changed: What|Removed |Added CC||adam...@gmail.com --- Comment #12 from Paul Floyd --- *** Bug 482013 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 483786] Incorrect parameter indexing in FreeBSD clock_nanosleep syscall wrapper
https://bugs.kde.org/show_bug.cgi?id=483786 Paul Floyd changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Paul Floyd --- Thanks for the patch and reproducer. I think that was me Author: Paul Floyd Date: Sun Jun 21 23:11:15 2020 +0200 Last bunch of syscalls + scalar for a bit Not a very helpful checkin comment. Thanks for the patch. I added the reproducer as a regression test and also slightly modified the POST so that rmtp only gets written if the syscall was interrupted. commit 8d8e4a889cc3a02a5c04e5c4f23f9a191b0a6726 (HEAD -> master, origin/master, origin/HEAD) Author: Paul Floyd Date: Sun Mar 17 07:41:42 2024 +0100 Bug 483786 -- Incorrect parameter indexing in FreeBSD clock_nanosleep syscall wrapper -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 483786] Incorrect parameter indexing in FreeBSD clock_nanosleep syscall wrapper
https://bugs.kde.org/show_bug.cgi?id=483786 Paul Floyd changed: What|Removed |Added Assignee|jsew...@acm.org |pjfl...@wanadoo.fr CC||pjfl...@wanadoo.fr -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 398569] invalid reads reported in libarmmem memcmp when using strings
https://bugs.kde.org/show_bug.cgi?id=398569 --- Comment #7 from Paul Floyd --- I've submitted a pull request here https://github.com/bavison/arm-mem/pull/12 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 483711] -m32 flag breaks Valgrind
https://bugs.kde.org/show_bug.cgi?id=483711 --- Comment #4 from Paul Floyd --- Can you provide an exe that reproduces the problem? As far as I know none of the Valgrind developers use Docker, and x86 isn't actively supported, so there's not much chance of this being fixed. It might help if you could build Valgrind from source and get a proper stacktrace from Valgrind. Many Linux packagers have decided that they know better than the Valgrind developers and they strip the Valgrind bninaries. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 483711] -m32 flag breaks Valgrind
https://bugs.kde.org/show_bug.cgi?id=483711 Paul Floyd changed: What|Removed |Added CC||pjfl...@wanadoo.fr --- Comment #1 from Paul Floyd --- 3.16.1 is fairly old, can you try something more recent? Docker doesn't seem to be a good environment for running Valgrind. I've never used it but I keep hearing of problems. I don't think that Docker does a good enough job of virtualizaton. Valgrind works better either on a real OS or on full virtualization systems like VirtualBox and VMware. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481874] Add arm64 support for FreeBSD
https://bugs.kde.org/show_bug.cgi?id=481874 Paul Floyd changed: What|Removed |Added Attachment #167164|0 |1 is obsolete|| --- Comment #8 from Paul Floyd --- Created attachment 167199 --> https://bugs.kde.org/attachment.cgi?id=167199=edit Patch with fix for PPC -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481874] Add arm64 support for FreeBSD
https://bugs.kde.org/show_bug.cgi?id=481874 --- Comment #7 from Paul Floyd --- (In reply to Paul Floyd from comment #6) > Created attachment 167164 [details] > Add FreeBSD arm64 support Broke ppc64. Will try again soon. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481874] Add arm64 support for FreeBSD
https://bugs.kde.org/show_bug.cgi?id=481874 --- Comment #6 from Paul Floyd --- Created attachment 167164 --> https://bugs.kde.org/attachment.cgi?id=167164=edit Add FreeBSD arm64 support -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481874] Add arm64 support for FreeBSD
https://bugs.kde.org/show_bug.cgi?id=481874 --- Comment #5 from Paul Floyd --- Most of the changes are the stuff that's needed for any new VGP: adding VGP_arm64_freebsd to may places, implementing initimg, aspacemgr, debuglog, syscall, sigframe, trampoline, vki headers. There is no brk function so I had to disable that in the tests. I had a lot of problems with none/tests/arm64. clang really did not like the GCC dialect or aarch64 assembler. I had to fix a lot of errors - use of redundant offsets that GCC accepts but clang rejects - use of x registers where w registers should be used There were also a huge number of warnings (I still haven't fixed them all). I added new expecteds for fp_and_simd because there's a printf of a nan that has the topmost (negative) bit set. glibc outputs "-nan" but FreeBSD libc outputs just "nan". The behaviour is defined as platform dependent in the C standard. Nevertheless I did open a bugzilla item for it https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277612 . There's also a new expected for memory. The problem here is that the testcase reads its own code, which is using inline assembler. That means it is at the mercy of the compiler for the register allocation. GCC uses x0, clang uses x8. Maybe the testcase should be modified to select opcodes that don't depend on the compiler. Next few steps - clean up the none tests warnings - test on buildbot - test on a few cfarm machines -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 481874] Add arm64 support for FreeBSD
https://bugs.kde.org/show_bug.cgi?id=481874 --- Comment #4 from Paul Floyd --- == 725 tests, 4 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures == memcheck/tests/descr_belowsp (stderr) memcheck/tests/manuel1 (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/thread_alloca (stderr) The first one is a known issue, both the kernel and libthr add guard pages to pthread stacks. The second one is flaky. I haven't looked at the third one. The last one is intermittent. Maybe a real error in ldrt. $ git diff --stat master Makefile.all.am | 4 + Makefile.tool.am |11 + NEWS | 7 +- VEX/auxprogs/genoffsets.c | 1 + VEX/priv/guest_arm64_defs.h | 2 +- VEX/priv/guest_arm64_helpers.c|22 + VEX/priv/guest_arm64_toIR.c |19 +- VEX/pub/libvex_guest_amd64.h | 7 - VEX/pub/libvex_guest_arm64.h |14 +- configure.ac |92 +- coregrind/Makefile.am | 4 + coregrind/launcher-freebsd.c | 6 +- coregrind/m_aspacemgr/aspacemgr-common.c | 2 +- coregrind/m_aspacemgr/aspacemgr-linux.c | 6 + coregrind/m_coredump/coredump-elf.c |73 + coregrind/m_debuginfo/d3basics.c | 2 +- coregrind/m_debuginfo/debuginfo.c |14 +- coregrind/m_debuginfo/readdwarf.c | 4 +- coregrind/m_debuginfo/readelf.c | 3 +- coregrind/m_debuglog.c|73 + coregrind/m_dispatch/dispatch-arm64-freebsd.S | 316 + coregrind/m_initimg/initimg-freebsd.c |21 + coregrind/m_libcassert.c | 2 +- coregrind/m_libcfile.c| 4 +- coregrind/m_libcproc.c| 4 +- coregrind/m_libcsetjmp.c | 144 +- coregrind/m_machine.c | 3 + coregrind/m_main.c|33 +- coregrind/m_redir.c | 2 +- coregrind/m_scheduler/scheduler.c | 2 +- coregrind/m_sigframe/sigframe-arm64-freebsd.c | 373 ++ coregrind/m_signals.c |23 + coregrind/m_stacktrace.c |10 +- coregrind/m_syscall.c |50 + coregrind/m_syswrap/priv_types_n_macros.h |22 +- coregrind/m_syswrap/syscall-arm64-freebsd.S | 195 + coregrind/m_syswrap/syswrap-arm64-freebsd.c | 1132 coregrind/m_syswrap/syswrap-freebsd.c |17 +- coregrind/m_syswrap/syswrap-main.c| 152 +- coregrind/m_trampoline.S |43 + coregrind/m_translate.c | 2 +- coregrind/pub_core_machine.h | 2 +- coregrind/pub_core_mallocfree.h | 1 + coregrind/pub_core_syscall.h | 1 + coregrind/pub_core_trampoline.h | 4 + coregrind/vgdb-invoker-freebsd.c |12 +- freebsd-drd.supp |11 +- freebsd-helgrind.supp | 5 + gdbserver_tests/mcsignopass.stderr.exp| 4 +- gdbserver_tests/mcsignopass.stdoutB.exp |48 +- gdbserver_tests/mcsigpass.stderr.exp | 4 +- gdbserver_tests/mcsigpass.stdoutB.exp |12 +- helgrind/tests/tc07_hbl1.c| 5 +- helgrind/tests/tc08_hbl2.c| 5 +- helgrind/tests/tc11_XCHG.c| 6 +- include/Makefile.am | 2 + include/pub_tool_libcsetjmp.h | 4 +- include/pub_tool_machine.h| 2 +- include/pub_tool_vkiscnums_asm.h | 2 +- include/valgrind.h.in |11 +- include/vki/vki-arm64-freebsd.h | 180 + include/vki/vki-freebsd.h |48 +- include/vki/vki-machine-types-arm64-freebsd.h |77 + massif/tests/Makefile.am | 5 +- massif/tests/pages_as_heap.vgtest | 1 + memcheck/tests/Makefile.am| 8 +- memcheck/tests/brk2.vgtest| 1 + memcheck/tests/freebsd/Makefile.am| 1 + memcheck/tests/freebsd/filter_context | 3 +- memcheck/tests/freebsd/filter_realpathat | 1 + memcheck/tests/freebsd/get_set_context.c
[valgrind] [Bug 471222] support tracking of file descriptors being double closed
https://bugs.kde.org/show_bug.cgi?id=471222 --- Comment #14 from Paul Floyd --- On second thoughts, isn't the fdleak_ipv4 double close message expected? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 471222] support tracking of file descriptors being double closed
https://bugs.kde.org/show_bug.cgi?id=471222 --- Comment #13 from Paul Floyd --- I had to modify double_close_range.c and socket_close.c like this #if defined(__linux__) #include #endif I get 3 new failures The first one has two things. Line number changes because of the Linux header. close/_close needs filtering. paulf> cat none/tests/socket_close*diff --- socket_close.stderr.exp 2024-03-10 10:30:00.201382000 +0100 +++ socket_close.stderr.out 2024-03-10 10:48:23.710309000 +0100 @@ -2,12 +2,12 @@ close socket_fd 3 and close the socket again 3 File descriptor 3: AF_UNIX socket 3: is already closed - at 0x: close (in /...libc...) - by 0x: main (socket_close.c:37) + at 0x: _close (in /...libc...) + by 0x: main (socket_close.c:39) Previously closed - at 0x: close (in /...libc...) - by 0x: main (socket_close.c:33) + at 0x: _close (in /...libc...) + by 0x: main (socket_close.c:35) Originally opened at 0x: socket (in /...libc...) - by 0x: open_socket (socket_close.c:14) - by 0x: main (socket_close.c:28) + by 0x: open_socket (socket_close.c:16) + by 0x: main (socket_close.c:30) The second one just needs a filter paulf> cat none/tests/file_dclose*diff --- file_dclose.stderr.exp 2024-03-10 10:30:00.199191000 +0100 +++ file_dclose.stderr.out 2024-03-10 10:47:29.153702000 +0100 @@ -1,13 +1,13 @@ close 3 time passes and we close 3 again File descriptor 3: file_dclose.tmp is already closed - at 0x: close (in /...libc...) + at 0x: _close (in /...libc...) by 0x: closefile (file_dclose.c:16) by 0x: main (file_dclose.c:32) Previously closed - at 0x: close (in /...libc...) + at 0x: _close (in /...libc...) by 0x: main (file_dclose.c:28) Originally opened - at 0x: creat (in /...libc...) + at 0x: _openat (in /...libc...) by 0x: openfile (file_dclose.c:10) by 0x: main (file_dclose.c:25) And the last one is new. --- fdleak_ipv4.stderr.exp 2024-03-10 10:30:00.197868000 +0100 +++ fdleak_ipv4.stderr.out 2024-03-10 10:47:25.622064000 +0100 @@ -1,4 +1,16 @@ +File descriptor 4: internet is already closed + at 0x: _close (in /...libc...) + by 0x: client (fdleak_ipv4.c:70) + by 0x: main (fdleak_ipv4.c:90) + Previously closed + at 0x: _close (in /...libc...) + by 0x: client (fdleak_ipv4.c:69) + by 0x: main (fdleak_ipv4.c:90) + Originally opened + at 0x: dup (in /...libc...) + by 0x: client (fdleak_ipv4.c:68) + by 0x: main (fdleak_ipv4.c:90) Is that a difference in the behaviour of fork between Linux and FreeBSD, or a but in my fork() code? Not sure. I can add the filters after you push the changes. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 471222] support tracking of file descriptors being double closed
https://bugs.kde.org/show_bug.cgi?id=471222 --- Comment #12 from Paul Floyd --- I'll test the new patch on FreeBSD tonight. -- You are receiving this mail because: You are watching all bug changes.
