valgrind-developers — Discussion list for developers of valgrind

[Valgrind-developers] [valgrind] Check ppoll ufds array is safe to deref before checking fd members

[Mark W. <ma...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=300d541a82d9966e833e4db9028011121253a19b

commit 300d541a82d9966e833e4db9028011121253a19b
Author: Mark Wielaard <ma...@kl...>
Date:   Fri Jul 11 17:18:47 2025 +0200

    Check ppoll ufds array is safe to deref before checking fd members
    
    LTP ppoll01 provides a bad fds array to ppoll as a testcase.
    memcheck should warn (through PRE_MEM_READ) this array is bad.
    But it shouldn't try to derefence anything if is isn't safe.

Diff:
---
 coregrind/m_syswrap/syswrap-linux.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/coregrind/m_syswrap/syswrap-linux.c b/coregrind/m_syswrap/syswrap-linux.c
index a5e1f9d656..51a47a16fb 100644
--- a/coregrind/m_syswrap/syswrap-linux.c
+++ b/coregrind/m_syswrap/syswrap-linux.c
@@ -2041,6 +2041,8 @@ static void ppoll_pre_helper ( ThreadId tid, SyscallArgLayout* layout,
    for (i = 0; i < ARG2; i++) {
       PRE_MEM_READ( "ppoll(ufds.fd)",
                     (Addr)(&ufds[i].fd), sizeof(ufds[i].fd) );
+      if (!ML_(safe_to_deref)(&ufds[i].fd, sizeof(ufds[i].fd)))
+         break;
       if (ufds[i].fd >= 0) {
          PRE_MEM_READ( "ppoll(ufds.events)",
                        (Addr)(&ufds[i].events), sizeof(ufds[i].events) );

[Valgrind-developers] [valgrind] Add fcntl14{, _64}, fcntl34{, _64} and fcntl36{, _64} to ltp-excludes.txt

[Mark W. <ma...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=0888c8b2289b450e87e92852e62d540bcd834b5a

commit 0888c8b2289b450e87e92852e62d540bcd834b5a
Author: Mark Wielaard <ma...@kl...>
Date:   Thu Jul 10 23:09:18 2025 +0200

    Add fcntl14{,_64}, fcntl34{,_64} and fcntl36{,_64} to ltp-excludes.txt
    
    These fcntl syscall tests time out and would need at least
    LTP_TIMEOUT_MUL=5 when run under memcheck, which is several minutes,
    so exclude them for now.

Diff:
---
 auxprogs/ltp-excludes.txt | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/auxprogs/ltp-excludes.txt b/auxprogs/ltp-excludes.txt
index 275fd74854..3b52dab8c7 100644
--- a/auxprogs/ltp-excludes.txt
+++ b/auxprogs/ltp-excludes.txt
@@ -16,3 +16,11 @@ setsockopt07
 signal05
 signal06
 timerfd_settime02
+# The following fcntl syscall tests time out, need at least
+# LTP_TIMEOUT_MUL=5 when run under memcheck
+fcntl14
+fcntl14_64
+fcntl34
+fcntl34_64
+fcntl36
+fcntl36_64

[Valgrind-developers] [valgrind] FreeBSD syscall: make syscall kenv unhandles actions a -v warning

[Paul F. <pa...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=b88f40e6557b1f16184230d686490bcffa2bd5eb

commit b88f40e6557b1f16184230d686490bcffa2bd5eb
Author: Paul Floyd <pj...@wa...>
Date:   Thu Jul 10 20:40:43 2025 +0200

    FreeBSD syscall: make syscall kenv unhandles actions a -v warning
    
    Was VG_(unimplemented) which bombs. That's a bit drastic for a syscall intented
    to be called directly by users.

Diff:
---
 coregrind/m_syswrap/syswrap-freebsd.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/coregrind/m_syswrap/syswrap-freebsd.c b/coregrind/m_syswrap/syswrap-freebsd.c
index 22053da7f5..e6e71c78d9 100644
--- a/coregrind/m_syswrap/syswrap-freebsd.c
+++ b/coregrind/m_syswrap/syswrap-freebsd.c
@@ -3708,8 +3708,10 @@ PRE(sys_kenv)
    case VKI_KENV_DUMP:
       break;
    default:
-      VG_(message)(Vg_UserMsg, "unhandled kenv cmd %" FMT_REGWORD "u", ARG1);
-      VG_(unimplemented) ("unhandled kenv cmd");
+      if (VG_(clo_verbosity) >= 1) {
+         VG_(umsg)("Warning: unimplemented kenv action: %" FMT_REGWORD "d\n",
+            ARG1);
+      }
       break;
    }
 }

[Valgrind-developers] [valgrind] FreeBSD syscall: remove duplicate dead code from sysarch PRE wrapper

[Paul F. <pa...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=1137bab53c18333e5057e5fc8910b362c4b9c6bd

commit 1137bab53c18333e5057e5fc8910b362c4b9c6bd
Author: Paul Floyd <pj...@wa...>
Date:   Thu Jul 10 20:20:20 2025 +0200

    FreeBSD syscall: remove duplicate dead code from sysarch PRE wrapper
    
    Probably a copy and paste error.

Diff:
---
 coregrind/m_syswrap/syswrap-amd64-freebsd.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/coregrind/m_syswrap/syswrap-amd64-freebsd.c b/coregrind/m_syswrap/syswrap-amd64-freebsd.c
index 4c69e762bd..21f22b5a8b 100644
--- a/coregrind/m_syswrap/syswrap-amd64-freebsd.c
+++ b/coregrind/m_syswrap/syswrap-amd64-freebsd.c
@@ -183,9 +183,6 @@ PRE(sys_sysarch)
          SET_STATUS_Failure( VKI_EINVAL );
       }
       break;
-
-      PRINT("sys_amd64_set_tlsbase ( %#lx )", ARG2);
-      break;
    default:
       VG_(message) (Vg_UserMsg, "unhandled sysarch cmd %lu", ARG1);
       VG_(unimplemented) ("unhandled sysarch cmd");

[Valgrind-developers] [valgrind] Suppress unimplemented fcntl command warning with -q

[Mark W. <ma...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=aec4871f7c9deed31f5d5606e4f9d07b43a448ec

commit aec4871f7c9deed31f5d5606e4f9d07b43a448ec
Author: Mark Wielaard <ma...@kl...>
Date:   Wed Jul 9 18:27:17 2025 +0200

    Suppress unimplemented fcntl command warning with -q
    
    LTP tests fcntl13 and fcntl13_64 fail because even with -q valgrind
    emits warnings about unknown (999) fcntl commands. Don't emit that
    message with -q, just fail with EINVAL.

Diff:
---
 coregrind/m_syswrap/syswrap-linux.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/coregrind/m_syswrap/syswrap-linux.c b/coregrind/m_syswrap/syswrap-linux.c
index 1eaa2621e6..a5e1f9d656 100644
--- a/coregrind/m_syswrap/syswrap-linux.c
+++ b/coregrind/m_syswrap/syswrap-linux.c
@@ -7202,8 +7202,9 @@ PRE(sys_fcntl)
    default:
       PRINT("sys_fcntl[UNKNOWN] ( %" FMT_REGWORD "u, %" FMT_REGWORD "u, %"
             FMT_REGWORD "u )", ARG1, ARG2, ARG3);
-      VG_(umsg)("Warning: unimplemented fcntl command: %" FMT_REGWORD "u\n",
-                ARG2);
+      if (VG_(clo_verbosity) >= 1)
+         VG_(umsg)("Warning: unimplemented fcntl command: %" FMT_REGWORD "u\n",
+                   ARG2);
       SET_STATUS_Failure( VKI_EINVAL );
       break;
    }

[Valgrind-developers] [valgrind] Better report which clone flag are problematic

[Mark W. <ma...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=1f39c9582bc6ca4470b202c6b61d477ec3abfce7

commit 1f39c9582bc6ca4470b202c6b61d477ec3abfce7
Author: Mark Wielaard <ma...@kl...>
Date:   Wed Jul 9 13:04:51 2025 +0200

    Better report which clone flag are problematic
    
    Be explict about which combination of CLONE_VM, CLONE_FS, CLONE_FILES
    and CLONE_VFORK flags are supported and which combination isn't.
    
    https://bugs.kde.org/show_bug.cgi?id=506795

Diff:
---
 NEWS                                |  1 +
 coregrind/m_syswrap/syswrap-linux.c | 13 +++++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index fe56ee5267..ce162cb18c 100644
--- a/NEWS
+++ b/NEWS
@@ -52,6 +52,7 @@ are not entered into bugzilla tend to get forgotten about or ignored.
         AMD64_GET_TLSBASE
 505228  Wrap linux specific mseal syscall
 502968  Wrap linux specific syscalls 457 (listmount) and 458 (statmount)
+506795  Better report which clone flags are problematic
 
 To see details of a given bug, visit
   https://bugs.kde.org/show_bug.cgi?id=XXXXXX
diff --git a/coregrind/m_syswrap/syswrap-linux.c b/coregrind/m_syswrap/syswrap-linux.c
index f2e1c49790..1eaa2621e6 100644
--- a/coregrind/m_syswrap/syswrap-linux.c
+++ b/coregrind/m_syswrap/syswrap-linux.c
@@ -955,8 +955,17 @@ PRE(sys_clone)
                    "x\n", ARG_FLAGS);
       VG_(message)(Vg_UserMsg, "\n");
       VG_(message)(Vg_UserMsg, "The only supported clone() uses are:\n");
-      VG_(message)(Vg_UserMsg, " - via a threads library (LinuxThreads or NPTL)\n");
-      VG_(message)(Vg_UserMsg, " - via the implementation of fork or vfork\n");
+      VG_(message)(Vg_UserMsg,
+                   " - via a threads library (VM, FS and FILES flags set)\n");
+      VG_(message)(Vg_UserMsg,
+                   " - via the implementation of vfork (VFORK or VFORK and VM flags set)\n");
+      VG_(message)(Vg_UserMsg,
+                   " - via plain fork (no VM, FS, FILES, VFORK flags set)\n");
+      VG_(message)(Vg_UserMsg, " clone call had %s%s%s%sflags set\n",
+                   cloneflags & VKI_CLONE_VM ? "CLONE_VM " : "",
+                   cloneflags & VKI_CLONE_FS ? "CLONE_FS " : "",
+                   cloneflags & VKI_CLONE_FILES ? "CLONE_FILES " : "",
+                   cloneflags & VKI_CLONE_VFORK ? "CLONE_VFORK " : "");
       VG_(unimplemented)
          ("Valgrind does not support general clone().");
    }

[Valgrind-developers] [valgrind] Fix operand / result types of Iop_DivU128[E], Iop_ModU128 and their signed counterparts

[Florian K. <fk...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=644d68e9501dd5679194dd5c8e0d3ce24764a1d8

commit 644d68e9501dd5679194dd5c8e0d3ce24764a1d8
Author: Florian Krohm <fl...@ei...>
Date:   Wed Jul 9 20:15:46 2025 +0000

    Fix operand / result types of Iop_DivU128[E], Iop_ModU128 and their signed counterparts
    
    In libvex_ir.h these IROps are described to operate on Ity_I128 operands and produce a like typed result. This contradicts the specification in ir_defs.c
    (function typeOfprimop) which claims Ity_V128 for operands and result.
    
    Above IROps are used exclusively by ppc for the following opcodes:
    Iop_DivU128  --> vdivuq  Vector Divide Unsigned Quadword
    Iop_DivS128  --> vdivsq  Vector Divide Signed Quadword
    Iop_DivU128E --> vdiveuq Vector Divide Extended Unsigned Quadword
    Iop_DivS128E --> vdivesq Vector Divide Extended Signed Quadword
    Iop_ModU128  --> vmoduq  Vector Modulo Unsigned Quadword
    Iop_ModS128  --> vmodsq  Vector Modulo Signed Quadword
    
    Reading the ISA document, it is clear, that those opcodes perform an
    integer division / modulo operation. Technically, they work on vector
    registers, presumably because vector registers are the only resource
    wide enough to store a quadword. Perhaps that is where the confusion
    comes from.
    So Ity_I128 it is.

Diff:
---
 VEX/priv/ir_defs.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/VEX/priv/ir_defs.c b/VEX/priv/ir_defs.c
index 9e7fbf920e..ba61758d74 100644
--- a/VEX/priv/ir_defs.c
+++ b/VEX/priv/ir_defs.c
@@ -3694,10 +3694,12 @@ void typeOfPrimop ( IROp op,
       case Iop_MulI128by10E:
       case Iop_MulI128by10ECarry:
       case Iop_PwExtUSMulQAdd8x16:
-      case Iop_DivU128: case Iop_DivS128:
+         BINARY(Ity_V128,Ity_V128, Ity_V128);
+
+      case Iop_DivU128:  case Iop_DivS128:
       case Iop_DivU128E: case Iop_DivS128E:
       case Iop_ModU128:  case Iop_ModS128:
-         BINARY(Ity_V128,Ity_V128, Ity_V128);
+         BINARY(Ity_I128,Ity_I128, Ity_I128);
 
       case Iop_2xMultU64Add128CarryOut:
       case Iop_Perm8x16x2:

Re: [Valgrind-developers] typeOfPrimop fixes

[Paul F. <pj...@wa...>]

On 05/07/2025 21:02, Florian Krohm wrote:
> What are the operand types of Iop_DivU128[E], Iop_ModU128 and their 
> signed counterparts?
>
> In libvex_ir.h these IROps are described to operate on Ity_I128 
> operands and produce a like typed result. This contradicts the 
> specification in ir_defs.c
> function typeOfprimop which claims Ity_V128 for operands and result.
>
> Above IROps are used exclusively by ppc for the following opcodes:
> Iop_DivU128  --> vdivuq  Vector Divide Unsigned Quadword
> Iop_DivS128  --> vdivsq  Vector Divide Signed Quadword
> Iop_DivU128E --> vdiveuq Vector Divide Extended Unsigned Quadword
> Iop_DivS128E --> vdivesq Vector Divide Extended Signed Quadword
> Iop_ModU128  --> vmoduq  Vector Modulo Unsigned Quadword
> Iop_ModS128  --> vmodsq  Vector Modulo Signed Quadword
>
> Reading the ISA document, it is clear, that those opcodes perform an
> integer division / modulo operation. Technically, they work on vector
> registers, presumably because vector registers are the only resource
> wide enough to store a quadword. Perhaps that is where the confusion
> comes from.
> So Ity_I128 it is.
>
> Below patch regtested on ppc with no new failures.
>
> OK?
>
VEX isn't my strong point, but it sounds OK to me.

A+

Paul

[Valgrind-developers] [valgrind] Refactor IRICB

[Florian K. <fk...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=a9203727b159879ce17b1290bfe8cee97730c6ac

commit a9203727b159879ce17b1290bfe8cee97730c6ac
Author: Florian Krohm <fl...@ei...>
Date:   Tue Jul 8 09:45:47 2025 +0000

    Refactor IRICB
    
    So far there was only one application of IR injection, namely vbit-test.
    Soonish there will be another.
    Refactor the IRICB to separate out the structure for the application's
    payload.

Diff:
---
 VEX/priv/ir_inject.c                | 23 ++++++++++++++++++-----
 VEX/pub/libvex.h                    | 23 +++++++++++++++++++----
 memcheck/tests/vbit-test/main.c     |  2 +-
 memcheck/tests/vbit-test/valgrind.c |  4 ++--
 4 files changed, 40 insertions(+), 12 deletions(-)

diff --git a/VEX/priv/ir_inject.c b/VEX/priv/ir_inject.c
index e62a2d8506..f642c834db 100644
--- a/VEX/priv/ir_inject.c
+++ b/VEX/priv/ir_inject.c
@@ -46,13 +46,12 @@
 
 /* The IR Injection Control Block. vex_inject_ir will query its contents
    to construct IR statements for testing purposes. */
-static IRICB iricb;
-
+static IRICB the_iricb;
 
 void
 LibVEX_InitIRI(const IRICB *iricb_in)
 {
-   iricb = *iricb_in;  // copy in
+   the_iricb = *iricb_in;  // copy in
 }
 
 
@@ -190,9 +189,10 @@ store(IRSB *irsb, IREndness endian, HWord haddr, IRExpr *data)
 
 /* Inject IR stmts depending on the data provided in the control
    block iricb. */
-void
-vex_inject_ir(IRSB *irsb, IREndness endian)
+static void
+vex_inject_ir_vbit(IRSB *irsb, IREndness endian)
 {
+   IRICB_vbit_payload iricb = the_iricb.vbit;
    IRExpr *data, *rounding_mode, *opnd1, *opnd2, *opnd3, *opnd4;
 
    rounding_mode = NULL;
@@ -321,6 +321,19 @@ vex_inject_ir(IRSB *irsb, IREndness endian)
    }
 }
 
+void
+vex_inject_ir(IRSB *irsb, IREndness endian)
+{
+   switch (the_iricb.kind) {
+   case IRICB_vbit:
+      vex_inject_ir_vbit(irsb, endian);
+      break;
+
+   default:
+      vpanic("unknown IRICB kind");
+   }
+}
+
 /*---------------------------------------------------------------*/
 /*--- end                                         ir_inject.c ---*/
 /*---------------------------------------------------------------*/
diff --git a/VEX/pub/libvex.h b/VEX/pub/libvex.h
index 2dbfbe770e..870747d354 100644
--- a/VEX/pub/libvex.h
+++ b/VEX/pub/libvex.h
@@ -960,7 +960,13 @@ extern void LibVEX_ShowStats ( void );
 
 #define NO_ROUNDING_MODE (~0u)
 
-typedef 
+typedef
+   enum {
+      IRICB_vbit,
+   }
+   IRICB_t;
+
+typedef
    struct {
       IROp  op;        // the operation to perform
       HWord result;    // address of the result
@@ -976,14 +982,23 @@ typedef
       UInt  rounding_mode;
       UInt  num_operands; // excluding rounding mode, if any
       /* The following two members describe if this operand has immediate
-       *  operands. There are a few restrictions:
-       *    (1) An operator can have at most one immediate operand.
+       * operands. There are a few restrictions:
+       * (1) An operator can have at most one immediate operand.
        * (2) If there is an immediate operand, it is the right-most operand
-       *  An immediate_index of 0 means there is no immediate operand.
+       * An immediate_index of 0 means there is no immediate operand.
        */
       UInt immediate_type;  // size of immediate Ity_I8, Ity_16
       UInt immediate_index; // operand number: 1, 2
    }
+   IRICB_vbit_payload;
+
+typedef
+   struct {
+      IRICB_t kind;
+      union {
+         IRICB_vbit_payload vbit;
+      };
+   }
    IRICB;
 
 extern void LibVEX_InitIRI ( const IRICB * );
diff --git a/memcheck/tests/vbit-test/main.c b/memcheck/tests/vbit-test/main.c
index db829dddaa..d403652190 100644
--- a/memcheck/tests/vbit-test/main.c
+++ b/memcheck/tests/vbit-test/main.c
@@ -183,7 +183,7 @@ main(int argc, char *argv[])
 
       valgrind_vex_init_for_iri(&iricb);
 
-      switch (iricb.num_operands) {
+      switch (iricb.vbit.num_operands) {
       case 1:
          num_unary_tests += test_unary_op(op, data);
          break;
diff --git a/memcheck/tests/vbit-test/valgrind.c b/memcheck/tests/vbit-test/valgrind.c
index 55ff3647da..204bf57ac9 100644
--- a/memcheck/tests/vbit-test/valgrind.c
+++ b/memcheck/tests/vbit-test/valgrind.c
@@ -31,7 +31,7 @@
 IRICB
 new_iricb(const irop_t *op, test_data_t *data)
 {
-   IRICB cb;
+   IRICB_vbit_payload cb;
 
    cb.op = op->op;
    cb.result = (HWord)&data->result.value;
@@ -52,7 +52,7 @@ new_iricb(const irop_t *op, test_data_t *data)
    cb.immediate_index = op->immediate_index;
    cb.immediate_type  = op->immediate_type;
 
-   return cb;
+   return (IRICB) { .kind = IRICB_vbit, .vbit = cb };
 }

[Valgrind-developers] [valgrind] Fix VEX/useful/Makefile-vex again

[Paul F. <pa...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=e6be4dcf0d816d808ba3e53ec5b6d572a718f731

commit e6be4dcf0d816d808ba3e53ec5b6d572a718f731
Author: Paul Floyd <pj...@wa...>
Date:   Tue Jul 8 08:27:20 2025 +0200

    Fix VEX/useful/Makefile-vex again
    
    Again a hard coded error, using cc. Replace that with ${CC} so that
    it uses the default system or user specified compiler.

Diff:
---
 VEX/useful/Makefile-vex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/VEX/useful/Makefile-vex b/VEX/useful/Makefile-vex
index 31eab20dbf..42d6d66eb4 100644
--- a/VEX/useful/Makefile-vex
+++ b/VEX/useful/Makefile-vex
@@ -2,7 +2,7 @@
 
 vex: test_main.c test_main.h ../pub/*.h ../priv/*.c ../priv/*.h
 	(cd ..; ${MAKE} -f Makefile-gcc)
-	cc -I../pub -o vex test_main.c ../libvex.a
+	${CC} -I../pub -o vex test_main.c ../libvex.a
 
 clean:
 	rm -f vex ../priv/*.o

[Valgrind-developers] [valgrind] Fix VEX/useful/Makefile-vex

[Paul F. <pa...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=71c4e60d7576795942f65234bfcbaa484d21ef08

commit 71c4e60d7576795942f65234bfcbaa484d21ef08
Author: Paul Floyd <pj...@wa...>
Date:   Tue Jul 8 08:14:56 2025 +0200

    Fix VEX/useful/Makefile-vex
    
    This uses hard coded 'make' which may mean Solaris make or
    BSD make ratheer than the initial invokation (e.g., gmake or some
    other make that is not first inthe PATH). Use ${MAKE} instead
    so that the same make is used for the second invokation.

Diff:
---
 VEX/useful/Makefile-vex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/VEX/useful/Makefile-vex b/VEX/useful/Makefile-vex
index 637afc9830..31eab20dbf 100644
--- a/VEX/useful/Makefile-vex
+++ b/VEX/useful/Makefile-vex
@@ -1,7 +1,7 @@
 # Crude makefile to build the "vex" executable from test_main.c
 
 vex: test_main.c test_main.h ../pub/*.h ../priv/*.c ../priv/*.h
-	(cd ..; make -f Makefile-gcc)
+	(cd ..; ${MAKE} -f Makefile-gcc)
 	cc -I../pub -o vex test_main.c ../libvex.a
 
 clean:

[Valgrind-developers] [valgrind] Fix VEX/Makefile-gcc

[Florian K. <fk...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=83c69fddf026be133c38d2b5a43c50eb1ce3e9ce

commit 83c69fddf026be133c38d2b5a43c50eb1ce3e9ce
Author: Florian Krohm <fl...@ei...>
Date:   Mon Jul 7 20:17:38 2025 +0000

    Fix VEX/Makefile-gcc
    
    Compile errors because config.h not found. Turns out libvex_inner.h
    Also missing was priv/host_generic_reg_alloc3.o causing linking to fail.
    Now fixed.

Diff:
---
 VEX/Makefile-gcc       | 5 +++++
 VEX/pub/libvex_inner.h | 2 --
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/VEX/Makefile-gcc b/VEX/Makefile-gcc
index 0b94e13c5f..57e33cdb25 100644
--- a/VEX/Makefile-gcc
+++ b/VEX/Makefile-gcc
@@ -68,6 +68,7 @@ LIB_OBJS = 	priv/ir_defs.o                          \
 		priv/host_generic_simd128.o	        \
 		priv/host_generic_simd256.o	        \
 		priv/host_generic_reg_alloc2.o		\
+		priv/host_generic_reg_alloc3.o		\
 		priv/guest_generic_x87.o	        \
 		priv/guest_generic_bb_to_IR.o		\
 		priv/guest_x86_helpers.o		\
@@ -347,6 +348,10 @@ priv/host_generic_reg_alloc2.o: $(ALL_HEADERS) priv/host_generic_reg_alloc2.c
 	$(CC) $(CCFLAGS) $(ALL_INCLUDES) -o priv/host_generic_reg_alloc2.o \
 					 -c priv/host_generic_reg_alloc2.c
 
+priv/host_generic_reg_alloc3.o: $(ALL_HEADERS) priv/host_generic_reg_alloc3.c
+	$(CC) $(CCFLAGS) $(ALL_INCLUDES) -o priv/host_generic_reg_alloc3.o \
+					 -c priv/host_generic_reg_alloc3.c
+
 priv/guest_x86_toIR.o: $(ALL_HEADERS) priv/guest_x86_toIR.c
 	$(CC) $(CCFLAGS) $(ALL_INCLUDES) -o priv/guest_x86_toIR.o \
 					 -c priv/guest_x86_toIR.c
diff --git a/VEX/pub/libvex_inner.h b/VEX/pub/libvex_inner.h
index 023d1f6a3e..f5db06d565 100644
--- a/VEX/pub/libvex_inner.h
+++ b/VEX/pub/libvex_inner.h
@@ -37,8 +37,6 @@
 // For more details, see README_DEVELOPPERS.
 //--------------------------------------------------------------------
 
-#include "config.h" 
-
 // The code of the inner Valgrind (core or tool code) contains client
 // requests (e.g. from helgrind.h, memcheck.h, ...) to help the
 // outer Valgrind finding (relevant) errors in the inner Valgrind.

[Valgrind-developers] [valgrind] Add vgstack to NEWS

[Paul F. <pa...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=65d7eaf98b2c284d2497cbc33c775199eacd77b1

commit 65d7eaf98b2c284d2497cbc33c775199eacd77b1
Author: Paul Floyd <pj...@wa...>
Date:   Mon Jul 7 20:05:50 2025 +0200

    Add vgstack to NEWS

Diff:
---
 NEWS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/NEWS b/NEWS
index 40fec35cd2..fe56ee5267 100644
--- a/NEWS
+++ b/NEWS
@@ -14,6 +14,12 @@ X86/macOS 10.13, AMD64/macOS 10.13 and nanoMIPS/Linux.
 
 * ==================== TOOL CHANGES ===================
 
+* There is a new utility script, "vgstack". It has two
+  option, -h for minimal help, and -v for the version information.
+  In normal use pass it the PID of a running Valgrind process
+  and it will perform a vgdb attach and print the backtrace(s)
+  of the guest executable.
+
 * ==================== FIXED BUGS ====================
 
 The following bugs have been fixed or resolved.  Note that "n-i-bz"

[Valgrind-developers] [valgrind] s390x: Minor fix for vbit-test

[Florian K. <fk...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=ce46882e02b38493fe921611cb3ee2d64bde8c30

commit ce46882e02b38493fe921611cb3ee2d64bde8c30
Author: Florian Krohm <fl...@ei...>
Date:   Mon Jul 7 13:51:29 2025 +0000

    s390x: Minor fix for vbit-test
    
    Add a big comment as to why Ity_I1 type values are stored in a
    32-bit entity.

Diff:
---
 VEX/priv/ir_inject.c                |  7 ++++---
 memcheck/tests/vbit-test/util.c     |  2 +-
 memcheck/tests/vbit-test/valgrind.c |  6 +++---
 memcheck/tests/vbit-test/vbits.h    | 14 +++++++++++++-
 4 files changed, 21 insertions(+), 8 deletions(-)

diff --git a/VEX/priv/ir_inject.c b/VEX/priv/ir_inject.c
index 26e8ca2787..e62a2d8506 100644
--- a/VEX/priv/ir_inject.c
+++ b/VEX/priv/ir_inject.c
@@ -67,7 +67,8 @@ load_aux(IREndness endian, IRType type, IRExpr *addr)
                   IRExpr_Load(endian, Ity_I64, addr));
    }
    if (type == Ity_I1) {
-      /* A Boolean value is stored as a 32-bit entity (see store_aux). */
+      /* A Boolean value is stored as a 32-bit entity. For an explanation
+         see comment in vbit-test/vbits.h */
       return unop(Iop_32to1, IRExpr_Load(endian, Ity_I32, addr));
    }
 
@@ -131,8 +132,8 @@ store_aux(IRSB *irsb, IREndness endian, IRExpr *addr, IRExpr *data)
       data = unop(Iop_ReinterpD64asI64, data);
    }
    if (typeOfIRExpr(irsb->tyenv, data) == Ity_I1) {
-      /* We cannot store a single bit. So we store it in a 32-bit container.
-         See also load_aux. */
+      /* A Boolean value is stored as a 32-bit entity. For an explanation
+         see comment in vbit-test/vbits.h */
       data = unop(Iop_1Uto32, data);
    }
    stmt(irsb, IRStmt_Store(endian, addr, data));
diff --git a/memcheck/tests/vbit-test/util.c b/memcheck/tests/vbit-test/util.c
index 63eabc8993..3e57cfa703 100644
--- a/memcheck/tests/vbit-test/util.c
+++ b/memcheck/tests/vbit-test/util.c
@@ -86,7 +86,7 @@ static void
 print_value(FILE *fp, value_t val, unsigned num_bits)
 {
    switch (num_bits) {
-   case 1:  fprintf(fp, "%02x",   val.u8);  break;
+   case 1:  fprintf(fp, "%01x",   val.u32); break; // see comment in vbits.h
    case 8:  fprintf(fp, "%02x",   val.u8);  break;
    case 16: fprintf(fp, "%04x",   val.u16); break;
    case 32: fprintf(fp, "%08x",   val.u32); break;
diff --git a/memcheck/tests/vbit-test/valgrind.c b/memcheck/tests/vbit-test/valgrind.c
index c24a06d649..55ff3647da 100644
--- a/memcheck/tests/vbit-test/valgrind.c
+++ b/memcheck/tests/vbit-test/valgrind.c
@@ -64,7 +64,7 @@ valgrind_set_vbits(opnd_t *opnd)
 {
    unsigned rc, num_bytes;
    
-   /* 1-bit wide values cannot be read. So we read a 4 bytes here */
+   /* 1-bit wide values cannot be read. So we read 4 bytes here */
    num_bytes = opnd->type == Ity_I1 ? 4 : sizeof_irtype(opnd->type);
    rc = VALGRIND_SET_VBITS(&opnd->value, &opnd->vbits.bits, num_bytes);
    assert(rc == 1);
@@ -83,8 +83,8 @@ valgrind_get_vbits(opnd_t *opnd)
 {
    unsigned rc, num_bytes;
 
-   /* 1-bit wide values cannot be stored. So we store them by writing a
-      single byte */
+   /* 1-bit wide values cannot be stored. So we store them by writing
+      4 bytes which is what ir_inject.c expects. */
    num_bytes = opnd->type == Ity_I1 ? 4 : sizeof_irtype(opnd->type);
    opnd->vbits.num_bits = bitsof_irtype(opnd->type);
    rc = VALGRIND_GET_VBITS(&opnd->value, &opnd->vbits.bits, num_bytes);
diff --git a/memcheck/tests/vbit-test/vbits.h b/memcheck/tests/vbit-test/vbits.h
index 53ba328aa0..7d0002d32f 100644
--- a/memcheck/tests/vbit-test/vbits.h
+++ b/memcheck/tests/vbit-test/vbits.h
@@ -48,7 +48,19 @@ typedef struct {
 
 /* A type large enough to hold any IRType'd value. At this point
    we do not expect to test with specific floating point values.
-   So we don't need to represent them. */
+   So we don't need to represent them.
+
+   NOTE: Values of type Ity_I1 are stored in the u32 variant. This is
+   inconsistent with the way such values are stored elsewhere in VEX,
+   namely, in an 8-bit container. Why is that?
+   The reason is that libvex_ir.h does not provide an Iop_8to1 operator.
+   However, that would be needed in ir_inject.c when loading a 1-bit value
+   from memory (see function load_aux there). Instead of today's
+      return unop(Iop_32to1, IRExpr_Load(endian, Ity_I32, addr));
+   we'd like to write
+      return unop(Iop_8to1, IRExpr_Load(endian, Ity_I8, addr));
+   But cannot do. Grrrrr...
+ */
 typedef union {
    uint8_t   u8;
    uint16_t  u16;

Re: [Valgrind-developers] Followup to c5218ff4c and some VEX cleanup

[Florian K. <fl...@ei...>]

Hi Paul,

thanks for looking at it.

On 06.07.25 22:15, Paul Floyd via Valgrind-developers wrote:
> 
> 
> For point 2
> 
> hd_fpu.c looks very old, pre-Valgrind even. The missing header looks like a 
> precursor to config.h and will probably be fairly easy to recreate. 

hd_fpu.c doesn't even have a main function. do_one_insn_fp is the entry
point which is a decoder. So you could possibly construct a main loop around it 
reading insns from some file or so. Still there are missing functions
that will prevent linking e.g. getIMem4, regno_from_modRM and amode_from_modRM
that do not exist elsewhere in the valgrind tree.

> x87_to_vex_and_back.c which is missing some riscv64 pieces. I'd need to get it 
> working in order to comment how useful it might be. Our x87 support is not 
> great, but no-one has time to work on it.
> 

OK, so we keep that one.

> smchash.c looks like a tool for checking hash values. Is that still of any use? 

Probably not. Nobody has used it when I was working on V between 2010 and 2016.

> For point 5, the initial commit comment is
> 
>      A very simple dynamic translator built on Vex, for the purpose of
>      debugging Vex using the binary-search-switchback technique
> 
> The Makefile refers to the ppc static library, so needs modifying to work on any 
> other platform.


Yes, I hacked that like so

all: switchback.c linker.c linker.h
	gcc -m32 -Wall -O -g -o switchback switchback.c linker.c \
		../libvex_x86_linux.a

and then you run into compiler errors related to the idiom recovery change which 
was added in 2019 in 558f5e9517a4. Clearly, switchback hasn't been used since.

> Maybe all these files should be in an "attic" directly with some text saying 
> that they are mostly forgotten.

I'd say: sometimes you just have to let go. The code base is 20+ years old, 
there are loads of BZs to fix and things that could be improved. Keeping and 
maintaining some cruft .... it's probably not a worthy endeavour.

> Back in "useful",
> 
> Is Makefile-vex any use? 

No. Makefile-vex simply invokes  ../Makefile-gcc to build the library. And 
Makefile-gcc is still there.

Cheers,

   Florian

Re: [Valgrind-developers] Followup to c5218ff4c and some VEX cleanup

[Paul F. <pj...@wa...>]

On 7/6/25 17:55, Florian Krohm wrote:
>
> Does that all sound OK ?
>
Hi Florian


For point 2

hd_fpu.c looks very old, pre-Valgrind even. The missing header looks 
like a precursor to config.h and will probably be fairly easy to 
recreate.  It looks like it's meant to create an object file that is a 
dependency for ...

x87_to_vex_and_back.c which is missing some riscv64 pieces. I'd need to 
get it working in order to comment how useful it might be. Our x87 
support is not great, but no-one has time to work on it.

smchash.c looks like a tool for checking hash values. Is that still of 
any use? Conceivably on new platforms.

For point 5, the initial commit comment is

     A very simple dynamic translator built on Vex, for the purpose of
     debugging Vex using the binary-search-switchback technique

The Makefile refers to the ppc static library, so needs modifying to 
work on any other platform.


Maybe all these files should be in an "attic" directly with some text 
saying that they are mostly forgotten.


Back in "useful",

Is Makefile-vex any use? It needs work on my system and it just builds 
libvex.a. Is that any different to the autotools produced 
VEX/libvex-ARCH-OS.a? It just looks a bit smaller.

Regards

Paul

[Valgrind-developers] Followup to c5218ff4c and some VEX cleanup

[Florian K. <fl...@ei...>]

VEX/useful/Makefile builds an executable that wants to read .orig files
which were removed in c5218ff4c. So this machinery can go.

Step #1: Remove associated files.

Changes to be committed:
   (use "git restore --staged <file>..." to unstage)
	deleted:    VEX/useful/Makefile-vex
	deleted:    VEX/useful/test_main.c
	deleted:    VEX/useful/test_main.h
	deleted:    VEX/useful/test_main.h.base

Step #2: The remaining files in VEX/useful could be useful as testcases.
However not all of them make sense:

hd_fpu.c   -- compile error: missing header file
smchash.c  -- wants to read some data from stdin
x87_to_vex_and_back.c -- compile error: missing header file

Therefore:

Changes to be committed:
   (use "git restore --staged <file>..." to unstage)
	deleted:    VEX/useful/hd_fpu.c
	deleted:    VEX/useful/smchash.c
	deleted:    VEX/useful/x87_to_vex_and_back.c

Step #3:
Merge the remaining .c files into VEX/test which seems to contain small testcases.
Remove directory "useful".

Step #4:
Remove directory "unused".

Step #5:
VEX/switchback
Building the "switchback" executable does not succeed because the changes from 
translation chaining were not applied here.
Does anybody know what this is supposed to do ?
Presumably this directory can be nuked as well.

Does that all sound OK ?

    Florian

[Valgrind-developers] typeOfPrimop fixes

[Florian K. <fl...@ei...>]

What are the operand types of Iop_DivU128[E], Iop_ModU128 and their signed 
counterparts?

In libvex_ir.h these IROps are described to operate on Ity_I128 operands and 
produce a like typed result. This contradicts the specification in ir_defs.c
function typeOfprimop which claims Ity_V128 for operands and result.

Above IROps are used exclusively by ppc for the following opcodes:
Iop_DivU128  --> vdivuq  Vector Divide Unsigned Quadword
Iop_DivS128  --> vdivsq  Vector Divide Signed Quadword
Iop_DivU128E --> vdiveuq Vector Divide Extended Unsigned Quadword
Iop_DivS128E --> vdivesq Vector Divide Extended Signed Quadword
Iop_ModU128  --> vmoduq  Vector Modulo Unsigned Quadword
Iop_ModS128  --> vmodsq  Vector Modulo Signed Quadword

Reading the ISA document, it is clear, that those opcodes perform an
integer division / modulo operation. Technically, they work on vector
registers, presumably because vector registers are the only resource
wide enough to store a quadword. Perhaps that is where the confusion
comes from.
So Ity_I128 it is.

Below patch regtested on ppc with no new failures.

OK?

diff --git a/VEX/priv/ir_defs.c b/VEX/priv/ir_defs.c
index 9e7fbf9..ba61758 100644
--- a/VEX/priv/ir_defs.c
+++ b/VEX/priv/ir_defs.c
@@ -3694,10 +3694,12 @@ void typeOfPrimop ( IROp op,
        case Iop_MulI128by10E:
        case Iop_MulI128by10ECarry:
        case Iop_PwExtUSMulQAdd8x16:
-      case Iop_DivU128: case Iop_DivS128:
+         BINARY(Ity_V128,Ity_V128, Ity_V128);
+
+      case Iop_DivU128:  case Iop_DivS128:
        case Iop_DivU128E: case Iop_DivS128E:
        case Iop_ModU128:  case Iop_ModS128:
-         BINARY(Ity_V128,Ity_V128, Ity_V128);
+         BINARY(Ity_I128,Ity_I128, Ity_I128);

        case Iop_2xMultU64Add128CarryOut:
        case Iop_Perm8x16x2:

[Valgrind-developers] [valgrind] Check dup2 oldfd before allowing the syscall

[Mark W. <ma...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=0dbd164e1767dc29a6e0ea8d2c86b02d6913043b

commit 0dbd164e1767dc29a6e0ea8d2c86b02d6913043b
Author: Mark Wielaard <ma...@kl...>
Date:   Sat Jul 5 00:51:36 2025 +0200

    Check dup2 oldfd before allowing the syscall
    
    The dup201 LTP test fails with TFAIL: dup2(1024, 5) succeeded
    
    That is because 1024 here is the soft file limit (so one higher than
    the max number of fds). Valgrind raises the soft limit a little
    internally to have a few private fds for itself. So this dup2 call
    succeeds (and possibly dups and internal valgrind fd into the
    newfd). We should check the oldfd before allowing the dup2 syscall,
    like we already check the newfd.

Diff:
---
 coregrind/m_syswrap/syswrap-generic.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/coregrind/m_syswrap/syswrap-generic.c b/coregrind/m_syswrap/syswrap-generic.c
index f8d73e1973..50deb1e764 100644
--- a/coregrind/m_syswrap/syswrap-generic.c
+++ b/coregrind/m_syswrap/syswrap-generic.c
@@ -3758,6 +3758,8 @@ PRE(sys_dup2)
 {
    PRINT("sys_dup2 ( %" FMT_REGWORD "u, %" FMT_REGWORD "u )", ARG1, ARG2);
    PRE_REG_READ2(long, "dup2", unsigned int, oldfd, unsigned int, newfd);
+   if (!ML_(fd_allowed)(ARG1, "dup2", tid, False))
+      SET_STATUS_Failure( VKI_EBADF );
    if (!ML_(fd_allowed)(ARG2, "dup2", tid, True))
       SET_STATUS_Failure( VKI_EBADF );
 }

[Valgrind-developers] [valgrind] Sanity check io_submit addresses before dereferencing

[Mark W. <ma...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=cd870f321b2ab0056b1e003afcf455a552642b22

commit cd870f321b2ab0056b1e003afcf455a552642b22
Author: Mark Wielaard <ma...@kl...>
Date:   Fri Jul 4 23:14:18 2025 +0200

    Sanity check io_submit addresses before dereferencing
    
    The LTP io_submit03 test fails under valgrind memcheck because it
    tests bad struct iocb attay addresses. Fix this by explicitly checking
    the struct iocb pointer and each array element pointer are safe to
    deref in the linux sys_io_submit PRE handler.

Diff:
---
 coregrind/m_syswrap/syswrap-linux.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/coregrind/m_syswrap/syswrap-linux.c b/coregrind/m_syswrap/syswrap-linux.c
index d2d0c70588..f2e1c49790 100644
--- a/coregrind/m_syswrap/syswrap-linux.c
+++ b/coregrind/m_syswrap/syswrap-linux.c
@@ -2690,12 +2690,15 @@ PRE(sys_io_submit)
                  vki_aio_context_t, ctx_id, long, nr,
                  struct iocb **, iocbpp);
    PRE_MEM_READ( "io_submit(iocbpp)", ARG3, ARG2*sizeof(struct vki_iocb *) );
-   if (ARG3 != 0) {
+   if (ML_(safe_to_deref)((void *)(Addr)ARG3, ARG2*sizeof(struct vki_iocb *))) {
       for (i = 0; i < ARG2; i++) {
          struct vki_iocb *cb = ((struct vki_iocb **)(Addr)ARG3)[i];
          struct vki_iovec *iov;
 
          PRE_MEM_READ( "io_submit(iocb)", (Addr)cb, sizeof(struct vki_iocb) );
+         if (!ML_(safe_to_deref)(&cb->aio_lio_opcode,
+                                 sizeof(cb->aio_lio_opcode)))
+            continue;
          switch (cb->aio_lio_opcode) {
          case VKI_IOCB_CMD_PREAD:
             PRE_MEM_WRITE( "io_submit(PREAD)", cb->aio_buf, cb->aio_nbytes );

[Valgrind-developers] [valgrind] Implement fcntl F_CREATED_QUERY

[Alexandra H. <aha...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=7615845dcd2166d98cb246e1ca7d4496cfcdfc4f

commit 7615845dcd2166d98cb246e1ca7d4496cfcdfc4f
Author: Alexandra Hájková <aha...@re...>
Date:   Fri Jul 4 07:35:13 2025 -0400

    Implement fcntl F_CREATED_QUERY
    
    Define VKI_F_CREATED_QUERY in vki-linux.h.
    Recognize it in PRE(sys_fcntl).
    This fixes ltp tests failures. When running:
    make ltpchecks TESTS="fcntl40 fcntl40_64
    the tests would fail with:
    fcntl40: unempty log2.filtered:
    ==1809471== Warning: unimplemented fcntl command: 1028
    
    https://bugs.kde.org/show_bug.cgi?id=506076

Diff:
---
 NEWS                                | 1 +
 coregrind/m_syswrap/syswrap-linux.c | 1 +
 include/vki/vki-linux.h             | 1 +
 3 files changed, 3 insertions(+)

diff --git a/NEWS b/NEWS
index c1940b56ce..40fec35cd2 100644
--- a/NEWS
+++ b/NEWS
@@ -23,6 +23,7 @@ bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather
 than mailing the developers (or mailing lists) directly -- bugs that
 are not entered into bugzilla tend to get forgotten about or ignored.
 
+506076  unimplemented fcntl command: 1028 (F_CREATED_QUERY)
 338803  Handling of dwz debug alt files or cross-CU is broken
 493434  Add --track-fds=bad mode (no "leak" tracking)
 503098  Incorrect NAN-boxing for float registers in RISC-V
diff --git a/coregrind/m_syswrap/syswrap-linux.c b/coregrind/m_syswrap/syswrap-linux.c
index 97d3862902..d2d0c70588 100644
--- a/coregrind/m_syswrap/syswrap-linux.c
+++ b/coregrind/m_syswrap/syswrap-linux.c
@@ -7100,6 +7100,7 @@ PRE(sys_fcntl)
    case VKI_F_GETSIG:
    case VKI_F_GETLEASE:
    case VKI_F_GETPIPE_SZ:
+   case VKI_F_CREATED_QUERY:
    case VKI_F_GET_SEALS:
       PRINT("sys_fcntl ( %" FMT_REGWORD "u, %" FMT_REGWORD "u )", ARG1, ARG2);
       PRE_REG_READ2(long, "fcntl", unsigned int, fd, unsigned int, cmd);
diff --git a/include/vki/vki-linux.h b/include/vki/vki-linux.h
index 65406fffe9..8c919845bc 100644
--- a/include/vki/vki-linux.h
+++ b/include/vki/vki-linux.h
@@ -1514,6 +1514,7 @@ struct vki_dirent64 {
 #define VKI_F_SETLEASE      (VKI_F_LINUX_SPECIFIC_BASE + 0)
 #define VKI_F_GETLEASE      (VKI_F_LINUX_SPECIFIC_BASE + 1)
 
+#define VKI_F_CREATED_QUERY (VKI_F_LINUX_SPECIFIC_BASE + 4)
 #define VKI_F_CANCELLK      (VKI_F_LINUX_SPECIFIC_BASE + 5)
 
 #define VKI_F_DUPFD_CLOEXEC (VKI_F_LINUX_SPECIFIC_BASE + 6)

[Valgrind-developers] [valgrind] FreeBSD syscall: harden sysctl kern.proc.pathname

[Paul F. <pa...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=924c0eadf1a948292ff1eeab162f85a3b2da3eb0

commit 924c0eadf1a948292ff1eeab162f85a3b2da3eb0
Author: Paul Floyd <pj...@wa...>
Date:   Thu Jul 3 22:06:49 2025 +0200

    FreeBSD syscall: harden sysctl kern.proc.pathname
    
    Add handling for NULL len pointer and not enough space
    for path. Also extend the bug470713 with a few more checks.
    
    Need to add some more inaccessible memory checks.

Diff:
---
 coregrind/m_syswrap/syswrap-freebsd.c       | 45 +++++++++++++++++++----------
 memcheck/tests/freebsd/bug470713.cpp        | 42 ++++++++++++++++++++-------
 memcheck/tests/freebsd/bug470713.stdout.exp |  6 ++--
 3 files changed, 66 insertions(+), 27 deletions(-)

diff --git a/coregrind/m_syswrap/syswrap-freebsd.c b/coregrind/m_syswrap/syswrap-freebsd.c
index 3f4b6ca712..22053da7f5 100644
--- a/coregrind/m_syswrap/syswrap-freebsd.c
+++ b/coregrind/m_syswrap/syswrap-freebsd.c
@@ -1927,29 +1927,40 @@ static void sysctl_kern_usrstack(SizeT* out, SizeT* outlen)
    *outlen = sizeof(ULong);
 }
 
-static Bool sysctl_kern_proc_pathname(HChar *out, SizeT *len)
+static Int sysctl_kern_proc_pathname(HChar *out, SizeT *len)
 {
    const HChar *exe_name = VG_(resolved_exename);
+   // assert that exe_name is an absolute path
+   vg_assert(exe_name && exe_name[0] == '/');
 
    if (!len) {
-      return False;
+      return VKI_ENOMEM;
    }
 
+   if (!ML_(safe_to_deref)(len, sizeof(len))) {
+      // ???? check
+      return VKI_ENOMEM;
+   }
+
+   SizeT exe_name_length = VG_(strlen)(exe_name)+1;
    if (!out) {
-      HChar tmp[VKI_PATH_MAX];
-      if (!VG_(realpath)(exe_name, tmp)) {
-         return False;
-      }
-      *len = VG_(strlen)(tmp)+1;
-      return True;
+      *len = exe_name_length;
+      return 0;
    }
 
-   if (!VG_(realpath)(exe_name, out)) {
-      return False;
+   if (*len < exe_name_length) {
+      return VKI_ENOMEM;
    }
 
-   *len = VG_(strlen)(out)+1;
-   return True;
+   if (ML_(safe_to_deref)(out, exe_name_length)) {
+      VG_(strncpy)(out, exe_name, exe_name_length);
+   } else {
+      // ???? check
+      return VKI_EFAULT;
+   }
+
+   *len = exe_name_length;
+   return 0;
 }
 
 // SYS___sysctl   202
@@ -2031,7 +2042,7 @@ PRE(sys___sysctl)
    if (SARG2 == 2 && ML_(safe_to_deref)(name, 2*sizeof(int))) {
       if (name[0] == 1 && name[1] == 32) {
          if (sysctl_kern_ps_strings((SizeT*)ARG3, (SizeT*)ARG4)) {
-           SET_STATUS_Success(0);
+            SET_STATUS_Success(0);
          }
       }
    }
@@ -2043,8 +2054,12 @@ PRE(sys___sysctl)
       if (name[0] == 1 && name[1] == 14 && name[2] == 12) {
          vki_pid_t pid = (vki_pid_t)name[3];
          if (pid == -1 || pid == VG_(getpid)()) {
-            sysctl_kern_proc_pathname((HChar *)ARG3, (SizeT *)ARG4);
-            SET_STATUS_Success(0);
+            int res = sysctl_kern_proc_pathname((HChar *)ARG3, (SizeT *)ARG4);
+            if (res == 0) {
+               SET_STATUS_Success(0);
+            } else {
+               SET_STATUS_Failure(res);
+            }
          }
       }
    }
diff --git a/memcheck/tests/freebsd/bug470713.cpp b/memcheck/tests/freebsd/bug470713.cpp
index e07dba76b5..b49fb16642 100644
--- a/memcheck/tests/freebsd/bug470713.cpp
+++ b/memcheck/tests/freebsd/bug470713.cpp
@@ -18,29 +18,51 @@ int main(int argc, char **argv)
    int mib[] = { CTL_KERN, KERN_PROC, KERN_PROC_PATHNAME, -1};
    size_t len;
 
-   if (sysctl(mib, 4, NULL, &len, NULL, 0) != 0) {
-      cout << "sysctl failed to get path length: " << std::strerror(errno) << '\n';
+   if (argc < 2)
+   {
+      std::cout << "ERROR: missing argument, expected \"" << argv[0] << " {absolute path of " << argv[0] << "}\"\n";
       return -1;
    }
 
+   if (sysctl(mib, 4, nullptr, &len, nullptr, 0) != 0) {
+      cout << "ERROR: sysctl failed to get path length: " << std::strerror(errno) << '\n';
+      return -1;
+   }
+
+   // not for regtest, path length may vary
+   // std::cout << "read length " << len << '\n';
+
    std::unique_ptr<char[]> aResult(new char[len]);
 
-   if (sysctl(mib, 4, aResult.get(), &len, NULL, 0) != 0)  {
-      cout << "sysctl failed to get path: " << strerror(errno) << '\n';
+   if (sysctl(mib, 4, aResult.get(), &len, nullptr, 0) != 0)  {
+      cout << "ERROR: sysctl failed to get path: " << strerror(errno) << '\n';
       return -1;
    }
 
    if (string(aResult.get()) == argv[1]) {
-      cout << "OK\n";
+      cout << "OK: got expected pathname\n";
+   } else {
+      cout << "ERROR: aResult " << aResult.get() << " argv[1] " << argv[1] << '\n';
+   }
+
+   if (sysctl(mib, 4, aResult.get(), nullptr, nullptr, 0) != 0)  {
+      cout << "OK: sysctl failed with nullptr length: " << strerror(errno) << '\n';
+   } else {
+      cout << "ERROR: nullptr length sysctl succeeded when it should have failed\n";
+   }
+
+   size_t bad_len = len - 3U;
+   if (sysctl(mib, 4, aResult.get(), &bad_len, nullptr, 0) != 0)  {
+      cout << "OK: sysctl failed to get path with bad_len: " << strerror(errno) << '\n';
    } else {
-      cout << "Not OK aResult " << aResult.get() << " argv[1] " << argv[1] << '\n';
+      cout << "ERROR: bad_len sysctl succeeded when it should have failed\n";
+      return -1;
    }
 
-   if (sysctl(mib, 4, NULL, NULL, NULL, 0) != -1) {
-      cout << "OK syscall failed\n";
+   if (sysctl(mib, 4, nullptr, &len, nullptr, 0) != -1) {
+      cout << "OK: sysctl failed with nullptr name: " << strerror(errno) << '\n';
       return -1;
    } else {
-      cout << "sysctl succeeded when it should have failed\n";
+      cout << "ERROR: nullptr name sysctl succeeded when it should have failed\n";
    }
 }
-
diff --git a/memcheck/tests/freebsd/bug470713.stdout.exp b/memcheck/tests/freebsd/bug470713.stdout.exp
index 2ba70ed13d..76dc05b5a0 100644
--- a/memcheck/tests/freebsd/bug470713.stdout.exp
+++ b/memcheck/tests/freebsd/bug470713.stdout.exp
@@ -1,2 +1,4 @@
-OK
-OK syscall failed
+OK: got expected pathname
+OK: sysctl failed with nullptr length: Cannot allocate memory
+OK: sysctl failed to get path with bad_len: Cannot allocate memory
+OK: sysctl failed with nullptr name: Cannot allocate memory

Re: [Valgrind-developers] bloat: [valgrind] s390x: Add script s390-runone to help debugging small code snippets

[Paul F. <pj...@wa...>]

On 6/30/25 20:29, John Reiser wrote:
>
> Four lines suffice:
>
> ===== iefbr14.S  ## old timers will remember the name from 60 years ago
> // build+run:  gcc -nostartfiles -nostdlib iefbr14.S;  valgrind ./a.out
> _start: .globl _start
>   << insert code snippet here >>
>         br %r14
> =====
>
Hmm. Verbose, commented code that is easy to use and not performance 
critical.

Or terse code with a cryptic filename that dates back to before I was born.

Tough choice.

A+

Paul

[Valgrind-developers] [valgrind] s390x: Fix diagnostic for S390_DECODE_UNKNOWN_SPECIAL_INSN

[Florian K. <fk...@so...>]

https://sourceware.org/cgit/valgrind/commit/?id=c56fbcb7c6e8c821be67c7e8d317116f5deff274

commit c56fbcb7c6e8c821be67c7e8d317116f5deff274
Author: Florian Krohm <fl...@ei...>
Date:   Mon Jun 30 19:31:33 2025 +0000

    s390x: Fix diagnostic for S390_DECODE_UNKNOWN_SPECIAL_INSN
    
    When decoding fails the insn bytes (at most 6) are shown. However,
    "special insns" are 10 bytes with the last 2 bytes being the interesting
    ones. Print them all.

Diff:
---
 VEX/priv/guest_s390_toIR.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/VEX/priv/guest_s390_toIR.c b/VEX/priv/guest_s390_toIR.c
index b3ee122c5a..f40cd15e85 100644
--- a/VEX/priv/guest_s390_toIR.c
+++ b/VEX/priv/guest_s390_toIR.c
@@ -23881,12 +23881,10 @@ s390_decode_and_irgen(const UChar *bytes, UInt insn_length, DisResult *dres)
          vpanic("s390_decode_and_irgen");
       }
 
-      vex_printf("%02x%02x", bytes[0], bytes[1]);
-      if (insn_length > 2) {
-         vex_printf(" %02x%02x", bytes[2], bytes[3]);
-      }
-      if (insn_length > 4) {
-         vex_printf(" %02x%02x", bytes[4], bytes[5]);
+      for (unsigned i = 0; i < insn_length; i += 2) {
+         if (i != 0)
+            vex_printf(" ");
+         vex_printf("%02x%02x", bytes[i], bytes[i + 1]);
       }
       vex_printf("\n");
    }

[Valgrind-developers] bloat: [valgrind] s390x: Add script s390-runone to help debugging small code snippets

[John R. <jr...@bi...>]

> https://sourceware.org/cgit/valgrind/commit/?id=56d870ba62c775ac5a97f95fc6efb49610cdf96e

> commit 56d870ba62c775ac5a97f95fc6efb49610cdf96e

>      s390x: Add script s390-runone to help debugging small code snippet

Four lines suffice:

===== iefbr14.S  ## old timers will remember the name from 60 years ago
// build+run:  gcc -nostartfiles -nostdlib iefbr14.S;  valgrind ./a.out
_start: .globl _start
   << insert code snippet here >>
         br %r14
=====