valgrind-developers — Discussion list for developers of valgrind

Re: [Valgrind-developers] ir_opt.c tweaks

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

Hi Florian,

On Wed, Jun 18, 2025 at 11:02:30AM +0200, Florian Krohm wrote:
> I was doing some tests with --vex-iropt-verbosity and noticed a
> few unhandled cases in constant folding. The patch below fixes
> those. There are more tweaks that could possibly be added to
> constant folding but I did not attempt that.

Do you happen to have a list or is there a bug for "missing constant
folding oppertunities" that someone could try?

> Added new functions mkFalse and mkTrue for readability.
> 
> Regtested on amd64 and s390x with no differences.

Maybe test on a 32bit arch, but I don't immediately see anything
suspicious. There are a couple (i386 and armhf) in the buildbot so
we'll see.

> diff --git a/VEX/priv/ir_opt.c b/VEX/priv/ir_opt.c
> index 656537865..6b75119ab 100644
> --- a/VEX/priv/ir_opt.c
> +++ b/VEX/priv/ir_opt.c
> @@ -1262,7 +1262,6 @@ static Bool notBool ( Bool b )
>  static IRExpr* mkZeroOfPrimopResultType ( IROp op )
>  {
>     switch (op) {
> -      case Iop_CmpNE32: return IRExpr_Const(IRConst_U1(toBool(0)));
>        case Iop_Xor8:  return IRExpr_Const(IRConst_U8(0));
>        case Iop_Xor16: return IRExpr_Const(IRConst_U16(0));
>        case Iop_Sub32:
> @@ -1278,14 +1277,23 @@ static IRExpr* mkZeroOfPrimopResultType ( IROp op )
>     }
>  }

OK, if mkZeroOfPrimopResultType is called with Iop_CmpNE32 it will now
vpanic, so we would know pretty quickly if we forgot to adjust some
callsite.

> +/* Make a Boolean False value */
> +static inline IRExpr* mkFalse(void)
> +{
> +   return IRExpr_Const(IRConst_U1(toBool(0)));
> +}
> +
> +/* Make a Boolean True value */
> +static inline IRExpr* mkTrue(void)
> +{
> +   return IRExpr_Const(IRConst_U1(toBool(1)));
> +}

Ack.

>  /* Make a value containing all 1-bits, which has the same type as the
>     result of the given primop. */
>  static IRExpr* mkOnesOfPrimopResultType ( IROp op )
>  {
>     switch (op) {
> -      case Iop_CmpEQ32:
> -      case Iop_CmpEQ64:
> -         return IRExpr_Const(IRConst_U1(toBool(1)));
>        case Iop_Or8:
>           return IRExpr_Const(IRConst_U8(0xFF));
>        case Iop_Or16:

OK, same as mkZeroOfPrimopResultType above.

> @@ -1440,6 +1448,13 @@ static IRExpr* fold_Expr_WRK ( IRExpr** env, IRExpr* e )
>              e2 = IRExpr_Const(IRConst_U32(u32));
>              break;
>           }
> +         case Iop_8Sto64: {
> +            ULong u64 = e->Iex.Unop.arg->Iex.Const.con->Ico.U8;
> +            u64 <<= 56;
> +            u64 = (Long)u64 >> 56;   /* signed shift */
> +            e2 = IRExpr_Const(IRConst_U64(u64));
> +            break;
> +         }

That looks correct.

>           case Iop_16Sto32: {
>              UInt u32 = e->Iex.Unop.arg->Iex.Const.con->Ico.U16;
>              u32 <<= 16;
> @@ -1474,6 +1489,12 @@ static IRExpr* fold_Expr_WRK ( IRExpr** env, IRExpr* e )
>              e2 = IRExpr_Const(IRConst_U32(
>                      0xFFFF & e->Iex.Unop.arg->Iex.Const.con->Ico.U16));
>              break;
> +         case Iop_32HIto16: {
> +            UInt w32 = e->Iex.Unop.arg->Iex.Const.con->Ico.U32;
> +            w32 >>= 16;
> +            e2 = IRExpr_Const(IRConst_U16(toUShort(w32)));
> +            break;
> +         }

Also looks correct, the toUShort will mask to 0xFFFF.

>           case Iop_32to16:
>              e2 = IRExpr_Const(IRConst_U16(toUShort(
>                      0xFFFF & e->Iex.Unop.arg->Iex.Const.con->Ico.U32)));
> @@ -1779,6 +1800,11 @@ static IRExpr* fold_Expr_WRK ( IRExpr** env, IRExpr* e )
>           switch (e->Iex.Binop.op) {
>  
>              /* -- Or -- */
> +            case Iop_Or1:
> +               e2 = IRExpr_Const(IRConst_U1(toBool(
> +                       (e->Iex.Binop.arg1->Iex.Const.con->Ico.U1
> +                        | e->Iex.Binop.arg2->Iex.Const.con->Ico.U1))));
> +               break;

OK.

>              case Iop_Or8:
>                 e2 = IRExpr_Const(IRConst_U8(toUChar( 
>                         (e->Iex.Binop.arg1->Iex.Const.con->Ico.U8
> @@ -2432,14 +2458,31 @@ static IRExpr* fold_Expr_WRK ( IRExpr** env, IRExpr* e )
>                 }
>                 break;
>  
> +            case Iop_ExpCmpNE8:
> +            case Iop_ExpCmpNE16:
> +            case Iop_ExpCmpNE32:
> +            case Iop_ExpCmpNE64:
> +            case Iop_CmpLT32S:
> +            case Iop_CmpLT64S:
> +            case Iop_CmpLE32S:
> +            case Iop_CmpLE64S:
> +            case Iop_CmpLT32U:
> +            case Iop_CmpLT64U:
> +            case Iop_CmpLE32U:
> +            case Iop_CmpLE64U:
> +            case Iop_CmpNE8:
> +            case Iop_CmpNE16:
>              case Iop_CmpNE32:
> -               /* CmpNE32(t,t) ==> 0, for some IRTemp t */
> +            case Iop_CmpNE64:
> +               /* Integer comparisons for some kind of inequality yield
> +                  'False' when both operands are identical. */
>                 if (sameIRExprs(env, e->Iex.Binop.arg1, e->Iex.Binop.arg2)) {
> -                  e2 = mkZeroOfPrimopResultType(e->Iex.Binop.op);
> +                  e2 = mkFalse();
>                    break;
>                 }

Yes, why only for Iop_CmpNE32 if you can do it for all integer
comparisons. Also mkFalse is indeed more clear.

>                 /* CmpNE32(1Uto32(b), 0) ==> b */
> -               if (isZeroU32(e->Iex.Binop.arg2)) {
> +               if (e->Iex.Binop.op == Iop_CmpNE32 &&
> +                   isZeroU32(e->Iex.Binop.arg2)) {
>                    IRExpr* a1 = chase(env, e->Iex.Binop.arg1);
>                    if (a1 && a1->tag == Iex_Unop 
>                           && a1->Iex.Unop.op == Iop_1Uto32) {

OK, the rest is still just Iop_CmpNE32.

> @@ -2449,10 +2492,17 @@ static IRExpr* fold_Expr_WRK ( IRExpr** env, IRExpr* e )
>                 }
>                 break;
>  
> -            // in total 32 bits
> +            case Iop_CmpEQ8:
> +            case Iop_CmpEQ16:
>              case Iop_CmpEQ32:
> -            // in total 64 bits
>              case Iop_CmpEQ64:
> +               /* CmpEQ8/16/32/64(t,t) ==> 1, for some IRTemp t */
> +               if (sameIRExprs(env, e->Iex.Binop.arg1, e->Iex.Binop.arg2)) {
> +                  e2 = mkTrue();
> +               }
> +               break;

OK, those got to true.

> +
> +            // in total 64 bits
>              case Iop_CmpEQ8x8:
>              case Iop_CmpEQ16x4:
>              case Iop_CmpEQ32x2:

And the rest still uses mkOnesOfPrimopResultType.

Looks good to me.

Thanks,

Mark

[Valgrind-developers] [valgrind] s390x: Robustise LibVEX_GuestS390X_initialise

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

https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=c6a5f3c5a573cefb1b351fd3d8997439525299d3

commit c6a5f3c5a573cefb1b351fd3d8997439525299d3
Author: Florian Krohm <fl...@ei...>
Date:   Wed Jun 18 21:10:17 2025 +0000

    s390x: Robustise LibVEX_GuestS390X_initialise

Diff:
---
 VEX/priv/guest_s390_helpers.c | 120 +-----------------------------------------
 1 file changed, 1 insertion(+), 119 deletions(-)

diff --git a/VEX/priv/guest_s390_helpers.c b/VEX/priv/guest_s390_helpers.c
index 6e0321feaa..335a9060b0 100644
--- a/VEX/priv/guest_s390_helpers.c
+++ b/VEX/priv/guest_s390_helpers.c
@@ -44,127 +44,9 @@
 void
 LibVEX_GuestS390X_initialise(VexGuestS390XState *state)
 {
-/*------------------------------------------------------------*/
-/*--- Initialise ar registers                              ---*/
-/*------------------------------------------------------------*/
-
-   state->guest_a0 = 0;
-   state->guest_a1 = 0;
-   state->guest_a2 = 0;
-   state->guest_a3 = 0;
-   state->guest_a4 = 0;
-   state->guest_a5 = 0;
-   state->guest_a6 = 0;
-   state->guest_a7 = 0;
-   state->guest_a8 = 0;
-   state->guest_a9 = 0;
-   state->guest_a10 = 0;
-   state->guest_a11 = 0;
-   state->guest_a12 = 0;
-   state->guest_a13 = 0;
-   state->guest_a14 = 0;
-   state->guest_a15 = 0;
-
-/*------------------------------------------------------------*/
-/*--- Initialise vr registers                             ---*/
-/*------------------------------------------------------------*/
-
-#define VRZERO(vr) \
-   do { \
-      vr.w64[0] = vr.w64[1] = 0ULL; \
-   } while(0);
-
-   VRZERO(state->guest_v0)
-   VRZERO(state->guest_v1)
-   VRZERO(state->guest_v2)
-   VRZERO(state->guest_v3)
-   VRZERO(state->guest_v4)
-   VRZERO(state->guest_v5)
-   VRZERO(state->guest_v6)
-   VRZERO(state->guest_v7)
-   VRZERO(state->guest_v8)
-   VRZERO(state->guest_v9)
-   VRZERO(state->guest_v10)
-   VRZERO(state->guest_v11)
-   VRZERO(state->guest_v12)
-   VRZERO(state->guest_v13)
-   VRZERO(state->guest_v14)
-   VRZERO(state->guest_v15)
-   VRZERO(state->guest_v16)
-   VRZERO(state->guest_v17)
-   VRZERO(state->guest_v18)
-   VRZERO(state->guest_v19)
-   VRZERO(state->guest_v20)
-   VRZERO(state->guest_v21)
-   VRZERO(state->guest_v22)
-   VRZERO(state->guest_v23)
-   VRZERO(state->guest_v24)
-   VRZERO(state->guest_v25)
-   VRZERO(state->guest_v26)
-   VRZERO(state->guest_v27)
-   VRZERO(state->guest_v28)
-   VRZERO(state->guest_v29)
-   VRZERO(state->guest_v30)
-   VRZERO(state->guest_v31)
-
-#undef VRZERO
-/*------------------------------------------------------------*/
-/*--- Initialise gpr registers                             ---*/
-/*------------------------------------------------------------*/
-
-   state->guest_r0 = 0;
-   state->guest_r1 = 0;
-   state->guest_r2 = 0;
-   state->guest_r3 = 0;
-   state->guest_r4 = 0;
-   state->guest_r5 = 0;
-   state->guest_r6 = 0;
-   state->guest_r7 = 0;
-   state->guest_r8 = 0;
-   state->guest_r9 = 0;
-   state->guest_r10 = 0;
-   state->guest_r11 = 0;
-   state->guest_r12 = 0;
-   state->guest_r13 = 0;
-   state->guest_r14 = 0;
-   state->guest_r15 = 0;
-
-/*------------------------------------------------------------*/
-/*--- Initialise S390 miscellaneous registers              ---*/
-/*------------------------------------------------------------*/
+   __builtin_memset(state, 0x0, sizeof *state);
 
-   state->guest_counter = 0;
-   state->guest_fpc = 0;
-   state->guest_IA = 0;
-
-/*------------------------------------------------------------*/
-/*--- Initialise S390 pseudo registers                     ---*/
-/*------------------------------------------------------------*/
-
-   state->guest_SYSNO = 0;
-
-/*------------------------------------------------------------*/
-/*--- Initialise generic pseudo registers                  ---*/
-/*------------------------------------------------------------*/
-
-   state->guest_NRADDR = 0;
-   state->guest_CMSTART = 0;
-   state->guest_CMLEN = 0;
-   state->guest_IP_AT_SYSCALL = 0;
    state->guest_EMNOTE = EmNote_NONE;
-   state->host_EvC_COUNTER = 0;
-   state->host_EvC_FAILADDR = 0;
-
-/*------------------------------------------------------------*/
-/*--- Initialise thunk                                     ---*/
-/*------------------------------------------------------------*/
-
-   state->guest_CC_OP = 0;
-   state->guest_CC_DEP1 = 0;
-   state->guest_CC_DEP2 = 0;
-   state->guest_CC_NDEP = 0;
-
-   __builtin_memset(state->padding, 0x0, sizeof(state->padding));
 }

[Valgrind-developers] [valgrind] s390x: Fix a comment

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

https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=e59f3c959102d6ca9f1791c0023f313a1be34030

commit e59f3c959102d6ca9f1791c0023f313a1be34030
Author: Florian Krohm <fl...@ei...>
Date:   Wed Jun 18 17:02:06 2025 +0000

    s390x: Fix a comment

Diff:
---
 VEX/priv/host_s390_defs.h | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/VEX/priv/host_s390_defs.h b/VEX/priv/host_s390_defs.h
index 48fbac7644..ddbaed5fe5 100644
--- a/VEX/priv/host_s390_defs.h
+++ b/VEX/priv/host_s390_defs.h
@@ -100,13 +100,10 @@ typedef enum {
 } s390_opnd_t;
 
 
-/* Naming convention for operand locations:
-   R    - GPR
-   I    - immediate value
-   M    - memory (any Amode may be used)
-*/
-
-/* An operand that is either in a GPR or is addressable via a BX20 amode */
+/* An operand that is either
+   R  located in a GPR   or
+   M  located in memory and addressable via any amode   or
+   I  an immediate integer constant */
 typedef struct {
    s390_opnd_t tag;
    union {

[Valgrind-developers] ir_opt.c tweaks

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

I was doing some tests with --vex-iropt-verbosity and noticed a
few unhandled cases in constant folding. The patch below fixes
those. There are more tweaks that could possibly be added to
constant folding but I did not attempt that.
Added new functions mkFalse and mkTrue for readability.

Regtested on amd64 and s390x with no differences.

OK?

   Florian

Re: [Valgrind-developers] headaches abound.. platform support

[Greg C. <cha...@wi...>]

Thanks for the honest feedback on this one..
I have my DEC alpha architecture books (ev3/ev4), and they give 
everything I would need, but they were published in 1992, which means 
they are for the 21064 and the pre-production ev3, and nothing later.  
Which sadly would only get me started.
There are 6 newer architectures for alpha (ev45,5,56,6,67,7) all of 
which have way more advanced stuff than the original chips.

It appears I should have looked into this a decade ago.. :(



On 2025/06/10 11:52, Paul Floyd via Valgrind-developers wrote:
> On 6/10/25 07:56, Tom Hughes via Valgrind-developers wrote:
> 
>> On 10/06/2025 00:30, John Reiser wrote:
>> It looks like just about every platform except alpha is supported,
>> so how much work is it to get a new platform supported (not sure how
>> much needs to be added/modified)?
>> 
>> Choose a supported $ARCH with 64-bit words and fixed-width
>> instructions:
>> 
>> $ grep -i arm64 $(find valgrind -name '*.[ch]')  |  wc -l
>> 5214
> 
> That's also a serious underestimate as there are whole files that
> are processor specific, like the basic CPU emulation:
> 
> Even counting for the fact that amd64 has probably more instructions
> than arm64, in VEX I see
> 
> $ cloc *arm64*c *arm64*h
> 
>  github.com/AlDanial/cloc v 2.04  T=0.04 s (153.5 files/s, 800954.5
> lines/s)
> -------------------------------------------------------------------------------
> 
> Language                     files          blank        comment
>     code
> -------------------------------------------------------------------------------
> 
> C                                4           2113           5552
>    22130
> C/C++ Header                     2            157            282
>     1072
> -------------------------------------------------------------------------------
> 
> SUM:                             6           2270           5834
>    23202
> -------------------------------------------------------------------------------
> 
> You will need to know the Alpha Reference Manual inside-out (about
> 1000 pages). If you are not already an expert in Alpha machine code
> then you will need to be very dedicated and be willing to spend a
> substantial amount of time working in it.
> 
> For reference, much of the Solaris amd64 port was does done for a
> masters thesis (typically 1 year). And that didn't require adding
> amd64 support.
> 
> Then there's the regression tests. We have over 100 amd64 tests. arm64
> is a bit weak, we only have 20 tests. Several of these are huge tests
> that use a python script to generate extensive coverage for opcodes
> with different register/memory modes.
> 
> A+
> 
> Paul
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers

[Valgrind-developers] [valgrind] Wrap linux specific mseal syscall

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

https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=9775bc496e4b6f80dec993e5d147356ebbe29fe3

commit 9775bc496e4b6f80dec993e5d147356ebbe29fe3
Author: Martin Cermak <mc...@re...>
Date:   Tue Jun 17 13:51:48 2025 +0200

    Wrap linux specific mseal syscall
    
    mseal takes address, size and flags.  Flags are reserved for
    future use. Modern CPUs support memory permissions such as RW and
    NX bits.  The mseal syscall takes address and size parameters to
    additionally protect memory mapping against modifications.
    
    FTR: https://docs.kernel.org/userspace-api/mseal.html
    
    Declare a sys_mseal wrapper in priv_syswrap-linux.h and hook it
    for {amd64,arm,arm64,mips64,nanomips,ppc32,ppc64,riscv64,s390x,x86}-linux
    using LINX_ with PRE handler in syswrap-linux.c
    
    https://bugs.kde.org/show_bug.cgi?id=505228

Diff:
---
 NEWS                                         | 1 +
 coregrind/m_syswrap/priv_syswrap-linux.h     | 3 +++
 coregrind/m_syswrap/syswrap-amd64-linux.c    | 1 +
 coregrind/m_syswrap/syswrap-arm-linux.c      | 1 +
 coregrind/m_syswrap/syswrap-arm64-linux.c    | 1 +
 coregrind/m_syswrap/syswrap-linux.c          | 9 +++++++++
 coregrind/m_syswrap/syswrap-mips32-linux.c   | 1 +
 coregrind/m_syswrap/syswrap-mips64-linux.c   | 1 +
 coregrind/m_syswrap/syswrap-nanomips-linux.c | 1 +
 coregrind/m_syswrap/syswrap-ppc32-linux.c    | 1 +
 coregrind/m_syswrap/syswrap-ppc64-linux.c    | 1 +
 coregrind/m_syswrap/syswrap-riscv64-linux.c  | 1 +
 coregrind/m_syswrap/syswrap-s390x-linux.c    | 1 +
 coregrind/m_syswrap/syswrap-x86-linux.c      | 1 +
 include/vki/vki-scnums-mips32-linux.h        | 1 +
 include/vki/vki-scnums-mips64-linux.h        | 1 +
 include/vki/vki-scnums-shared-linux.h        | 1 +
 17 files changed, 27 insertions(+)

diff --git a/NEWS b/NEWS
index 041d7afdf3..97e4b3b413 100644
--- a/NEWS
+++ b/NEWS
@@ -41,6 +41,7 @@ are not entered into bugzilla tend to get forgotten about or ignored.
 504919  Hide "client tried to modify addresses" warnings when -q (quiet) set
 504936  Add FreeBSD amd64 sysarch subcommands AMD64_SET_TLSBASE and
         AMD64_GET_TLSBASE
+505228  Wrap linux specific mseal syscall
 
 To see details of a given bug, visit
   https://bugs.kde.org/show_bug.cgi?id=XXXXXX
diff --git a/coregrind/m_syswrap/priv_syswrap-linux.h b/coregrind/m_syswrap/priv_syswrap-linux.h
index 966eae5437..ed8cb4ed50 100644
--- a/coregrind/m_syswrap/priv_syswrap-linux.h
+++ b/coregrind/m_syswrap/priv_syswrap-linux.h
@@ -355,6 +355,9 @@ DECL_TEMPLATE(linux, sys_pidfd_getfd);
 // Since Linux 6.6
 DECL_TEMPLATE(linux, sys_fchmodat2);
 
+// Since Linux 6.10
+DECL_TEMPLATE(linux, sys_mseal);
+
 /* ---------------------------------------------------------------------
    Wrappers for sockets and ipc-ery.  These are split into standalone
    procedures because x86-linux hides them inside multiplexors
diff --git a/coregrind/m_syswrap/syswrap-amd64-linux.c b/coregrind/m_syswrap/syswrap-amd64-linux.c
index c226831926..292e969fc1 100644
--- a/coregrind/m_syswrap/syswrap-amd64-linux.c
+++ b/coregrind/m_syswrap/syswrap-amd64-linux.c
@@ -904,6 +904,7 @@ static SyscallTableEntry syscall_table[] = {
 
    LINXY(__NR_cachestat,         sys_cachestat),         // 451
    LINX_(__NR_fchmodat2,         sys_fchmodat2),         // 452
+   LINX_(__NR_mseal,             sys_mseal),             // 462
 };
 
 SyscallTableEntry* ML_(get_linux_syscall_entry) ( UInt sysno )
diff --git a/coregrind/m_syswrap/syswrap-arm-linux.c b/coregrind/m_syswrap/syswrap-arm-linux.c
index 05cd1e4b65..6d7db0425b 100644
--- a/coregrind/m_syswrap/syswrap-arm-linux.c
+++ b/coregrind/m_syswrap/syswrap-arm-linux.c
@@ -1075,6 +1075,7 @@ static SyscallTableEntry syscall_main_table[] = {
 
    LINXY(__NR_cachestat,         sys_cachestat),         // 451
    LINX_(__NR_fchmodat2,         sys_fchmodat2),         // 452
+   LINX_(__NR_mseal,             sys_mseal),             // 462
 };
 
 
diff --git a/coregrind/m_syswrap/syswrap-arm64-linux.c b/coregrind/m_syswrap/syswrap-arm64-linux.c
index 28cb3647c4..2d6b45f916 100644
--- a/coregrind/m_syswrap/syswrap-arm64-linux.c
+++ b/coregrind/m_syswrap/syswrap-arm64-linux.c
@@ -855,6 +855,7 @@ static SyscallTableEntry syscall_main_table[] = {
 
    LINXY(__NR_cachestat,         sys_cachestat),         // 451
    LINX_(__NR_fchmodat2,         sys_fchmodat2),         // 452
+   LINX_(__NR_mseal,             sys_mseal),             // 462
 };
 
 
diff --git a/coregrind/m_syswrap/syswrap-linux.c b/coregrind/m_syswrap/syswrap-linux.c
index be936ecbe1..0db8717786 100644
--- a/coregrind/m_syswrap/syswrap-linux.c
+++ b/coregrind/m_syswrap/syswrap-linux.c
@@ -4296,6 +4296,15 @@ PRE(sys_membarrier)
    PRE_REG_READ1(int, "membarrier", int, flags);
 }
 
+PRE(sys_mseal)
+{
+    /* int mseal(void *addr, size_t len, unsigned long flags) */
+    PRINT("sys_mseal ( %#" FMT_REGWORD "x, %" FMT_REGWORD "u, %#" FMT_REGWORD "x, )", ARG1, ARG2, ARG3);
+    PRE_REG_READ3(int, "mseal", void *, addr,  vki_size_t, len, int, flags);
+    if (!ML_(valid_client_addr)(ARG1, ARG2, tid, "mseal"))
+       SET_STATUS_Failure(VKI_ENOMEM);
+}
+
 PRE(sys_syncfs)
 {
    *flags |= SfMayBlock;
diff --git a/coregrind/m_syswrap/syswrap-mips32-linux.c b/coregrind/m_syswrap/syswrap-mips32-linux.c
index d16a9a4bc1..5edae82c31 100644
--- a/coregrind/m_syswrap/syswrap-mips32-linux.c
+++ b/coregrind/m_syswrap/syswrap-mips32-linux.c
@@ -1182,6 +1182,7 @@ static SyscallTableEntry syscall_main_table[] = {
 
    LINXY(__NR_cachestat,               sys_cachestat),               // 451
    LINX_(__NR_fchmodat2,               sys_fchmodat2),               // 452
+   LINX_(__NR_mseal,                   sys_mseal),                   // 462
 };
 
 SyscallTableEntry* ML_(get_linux_syscall_entry) (UInt sysno)
diff --git a/coregrind/m_syswrap/syswrap-mips64-linux.c b/coregrind/m_syswrap/syswrap-mips64-linux.c
index fe1f3db7f5..63e4b111ec 100644
--- a/coregrind/m_syswrap/syswrap-mips64-linux.c
+++ b/coregrind/m_syswrap/syswrap-mips64-linux.c
@@ -838,6 +838,7 @@ static SyscallTableEntry syscall_main_table[] = {
    LINXY (__NR_cachestat, sys_cachestat),
    LINX_ (__NR_fchmodat2, sys_fchmodat2),
    LINXY (__NR_userfaultfd, sys_userfaultfd),
+   LINX_ (__NR_mseal, sys_mseal),
 };
 
 SyscallTableEntry * ML_(get_linux_syscall_entry) ( UInt sysno )
diff --git a/coregrind/m_syswrap/syswrap-nanomips-linux.c b/coregrind/m_syswrap/syswrap-nanomips-linux.c
index 87153737d3..b392ad1ade 100644
--- a/coregrind/m_syswrap/syswrap-nanomips-linux.c
+++ b/coregrind/m_syswrap/syswrap-nanomips-linux.c
@@ -842,6 +842,7 @@ static SyscallTableEntry syscall_main_table[] = {
    LINX_ (__NR_landlock_restrict_self, sys_landlock_restrict_self),
    LINXY (__NR_cachestat,              sys_cachestat),
    LINX_ (__NR_fchmodat2,              sys_fchmodat2),
+   LINX_ (__NR_mseal,                  sys_mseal),
 };
 
 SyscallTableEntry* ML_(get_linux_syscall_entry) (UInt sysno)
diff --git a/coregrind/m_syswrap/syswrap-ppc32-linux.c b/coregrind/m_syswrap/syswrap-ppc32-linux.c
index bc180b8b1c..9d02a02580 100644
--- a/coregrind/m_syswrap/syswrap-ppc32-linux.c
+++ b/coregrind/m_syswrap/syswrap-ppc32-linux.c
@@ -1081,6 +1081,7 @@ static SyscallTableEntry syscall_table[] = {
 
    LINXY(__NR_cachestat,         sys_cachestat),         // 451
    LINX_ (__NR_fchmodat2,        sys_fchmodat2),         // 452
+   LINX_ (__NR_mseal,            sys_mseal),             // 462
 };
 
 SyscallTableEntry* ML_(get_linux_syscall_entry) ( UInt sysno )
diff --git a/coregrind/m_syswrap/syswrap-ppc64-linux.c b/coregrind/m_syswrap/syswrap-ppc64-linux.c
index 6e97358e89..94385a4fa1 100644
--- a/coregrind/m_syswrap/syswrap-ppc64-linux.c
+++ b/coregrind/m_syswrap/syswrap-ppc64-linux.c
@@ -1048,6 +1048,7 @@ static SyscallTableEntry syscall_table[] = {
 
    LINXY (__NR_cachestat,        sys_cachestat),         // 451
    LINX_ (__NR_fchmodat2,        sys_fchmodat2),         // 452
+   LINX_ (__NR_mseal,            sys_mseal),             // 462
 };
 
 SyscallTableEntry* ML_(get_linux_syscall_entry) ( UInt sysno )
diff --git a/coregrind/m_syswrap/syswrap-riscv64-linux.c b/coregrind/m_syswrap/syswrap-riscv64-linux.c
index 7a1ff07518..68ccd0ea49 100644
--- a/coregrind/m_syswrap/syswrap-riscv64-linux.c
+++ b/coregrind/m_syswrap/syswrap-riscv64-linux.c
@@ -599,6 +599,7 @@ static SyscallTableEntry syscall_main_table[] = {
    LINXY(__NR_memfd_secret, sys_memfd_secret),                     /* 447 */
    LINXY(__NR_cachestat, sys_cachestat),                           /* 451 */
    LINX_(__NR_fchmodat2, sys_fchmodat2),                           /* 452 */
+   LINX_(__NR_mseal, sys_mseal),                                   /* 462 */
 };
 
 SyscallTableEntry* ML_(get_linux_syscall_entry)(UInt sysno)
diff --git a/coregrind/m_syswrap/syswrap-s390x-linux.c b/coregrind/m_syswrap/syswrap-s390x-linux.c
index f4ceae4613..a6770399dd 100644
--- a/coregrind/m_syswrap/syswrap-s390x-linux.c
+++ b/coregrind/m_syswrap/syswrap-s390x-linux.c
@@ -890,6 +890,7 @@ static SyscallTableEntry syscall_table[] = {
 
    LINXY (__NR_cachestat, sys_cachestat),                             // 451
    LINX_ (__NR_fchmodat2, sys_fchmodat2),                             // 452
+   LINX_ (__NR_mseal, sys_mseal),                                     // 462
 };
 
 SyscallTableEntry* ML_(get_linux_syscall_entry) ( UInt sysno )
diff --git a/coregrind/m_syswrap/syswrap-x86-linux.c b/coregrind/m_syswrap/syswrap-x86-linux.c
index 662780588a..4b5b5fb15f 100644
--- a/coregrind/m_syswrap/syswrap-x86-linux.c
+++ b/coregrind/m_syswrap/syswrap-x86-linux.c
@@ -1676,6 +1676,7 @@ static SyscallTableEntry syscall_table[] = {
 
    LINXY(__NR_cachestat,         sys_cachestat),         // 451
    LINX_(__NR_fchmodat2,         sys_fchmodat2),         // 452
+   LINX_(__NR_mseal,             sys_mseal),             // 462
 };
 
 SyscallTableEntry* ML_(get_linux_syscall_entry) ( UInt sysno )
diff --git a/include/vki/vki-scnums-mips32-linux.h b/include/vki/vki-scnums-mips32-linux.h
index d4f8de15aa..53f6499aab 100644
--- a/include/vki/vki-scnums-mips32-linux.h
+++ b/include/vki/vki-scnums-mips32-linux.h
@@ -460,6 +460,7 @@
 #define __NR_set_mempolicy_home_node    (__NR_Linux + 450)
 #define __NR_cachestat                  (__NR_Linux + 451)
 #define __NR_fchmodat2                  (__NR_Linux + 452)
+#define __NR_mseal                      (__NR_Linux + 462)
 /*
  * Offset of the last Linux o32 flavoured syscall
  */
diff --git a/include/vki/vki-scnums-mips64-linux.h b/include/vki/vki-scnums-mips64-linux.h
index c5291e31c6..91f5783457 100644
--- a/include/vki/vki-scnums-mips64-linux.h
+++ b/include/vki/vki-scnums-mips64-linux.h
@@ -401,6 +401,7 @@
 #define __NR_lsm_get_self_attr      (__NR_Linux + 459)
 #define __NR_lsm_set_self_attr      (__NR_Linux + 460)
 #define __NR_lsm_list_modules       (__NR_Linux + 461)
+#define __NR_mseal                  (__NR_Linux + 462)
 
 #elif defined(VGABI_N32)
 
diff --git a/include/vki/vki-scnums-shared-linux.h b/include/vki/vki-scnums-shared-linux.h
index 616f8052d3..32ef8ac133 100644
--- a/include/vki/vki-scnums-shared-linux.h
+++ b/include/vki/vki-scnums-shared-linux.h
@@ -56,5 +56,6 @@
 
 #define __NR_cachestat		451
 #define __NR_fchmodat2		452
+#define __NR_mseal		462
 
 #endif

Re: [Valgrind-developers] Switching to GPLv3+ for next release (Was: Using objdump code for disassembly)

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

On 17.06.25 11:53, Mark Wielaard wrote:
> 
>> The motivation seemed to be about replacing Valgrind's disassembly code
>> with some third-party code. Which sounds like an enormously large and
>> invasive change.
> 
> The direct motivation was indeed Florian wanting to reuse binutils
> objdump code to support the many extended mnemonics for s390 vector
> insns. I believe he already has a working patch for that, so maybe he
> could post that so you can see if it is a sane approach.
> 

Yes, I do have a working patch for s390. But it is not a good example to show 
because it is not examplary. Most of the changes are in the guest_s390_toIR.c 
code which is organised quite differently from the other architectures because 
large parts of it were generated from a machine description at the time.
So let me explain for amd64.

guest_amd64_toIR.c
The macro DIP and its 912 invocations will go away. This change is largely 
mechanical but one would have to make sure that the macro arguments have no side 
effects.
In function disInstr_AMD64_WRK after handling the "special insns" there would be 
a call to amd64_disasm(guest_code + delta) which performs the disassembly using 
the machinery from objdump and writes the result via vex_vsprintf.

For arm, ppc, mips, etc. this will be similar because they also use the 
venerable DIP macro.

host_amd64_defs.c
At the end of function  emit_AMD64Instr  call amd64_disasm(buf) again to show 
the disassembled insn.

So the patch will be biggish but largely because lots of code will be removed.

I think it makes sense to consolidate the disassembly business this way. Future 
architectures will get it almost for free.
And I'd be willing to do the work if that is so desired.

    Florian

Re: [Valgrind-developers] Switching to GPLv3+ for next release (Was: Using objdump code for disassembly)

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

Hi Nick,

On Tue, Jun 17, 2025 at 09:03:11AM +1000, Nicholas Nethercote wrote:
> I don't agree with the license update. At least, not without more
> discussion.

Sure. Lets discuss some more. Sorry for assuming we already got
consensus. I do think it is a good idea. But would not want to push
this through if there are core developers objecting.

> The motivation seemed to be about replacing Valgrind's disassembly code
> with some third-party code. Which sounds like an enormously large and
> invasive change.

The direct motivation was indeed Florian wanting to reuse binutils
objdump code to support the many extended mnemonics for s390 vector
insns. I believe he already has a working patch for that, so maybe he
could post that so you can see if it is a sane approach.

But having worked on the valgrind gdbserver and vgdb gdb integration
stuff which is derived from gdb gdbserver code when it was still
GPLv2+ I have also thought it would be really nice to upgrade that
(current GDB is also GPLv3+).

There are also bits and pieces in coregrind/m_debuginfo/readelf.c
taken from older binutils code (not sure if that can be easily
upgraded now though).

In general it would be nice if we can again take some existing code
from binutils and/or gdb to incorporate. And GPLv3 also has the
benefit of being a slightly nicer license (imho) that is easier to
comply with and is compatible with more other licenses (specifically
the Apache license, although I have no examples of Apache licensed
code that we might want to incorporate at this time).

> And the license discussion hasn't gotten any deeper than "that might be
> nice". License changes are serious, they should be taken seriously.

I think it has been a bit deeper than that with some concrete examples
of what benefits it brings. But yes, it is serious and it also is
actual work to do it correctly (which is why I will ask FSF legal to
help to get all the details right). I wouldn't want to do it if I
didn't think the benefits aren't worth it, or if other core developers
are against it.

Cheers,

Mark

> On Tue, 17 Jun 2025 at 02:53, Mark Wielaard <ma...@kl...> wrote:
> 
> > Hi all,
> >
> > Updating the subject to be explicit about the goal.
> >
> > On Thu, 2025-06-12 at 15:21 +0200, Andreas Arnez wrote:
> > > On Mon, Jun 02 2025, Mark Wielaard wrote:
> > > > On Sun, 2025-06-01 at 17:47 +0200, Paul Floyd wrote:
> > > > > On 6/1/25 15:22, Mark Wielaard wrote:
> > > > > > I think an upgrade to GPLv3+ for valgrind is a good idea. It would
> > > > > > also allow us to upgrade some gdbserver parts (various files under
> > > > > > coregrind/m_gdbserver). Note that the new vgstack utility is
> > already
> > > > > > derived from GPLv3+ code.
> > > > > >
> > > > > > We could make that a goal for 3.26.0 (or maybe that deserves
> > finally
> > > > > > going to 4.0?) for our October release. I can contact the FSF legal
> > > > > > team to ask if they want to help with or see any issues with such
> > an
> > > > > > upgrade if we want to incorporate more GPLv3+ code from the core
> > > > > > toolchain projects.
> > > > >
> > > > > Licence-wise, I don't have much of an opinion. It would be nice to
> > be
> > > > > able to integrate code more easily.
> > > > >
> > > > > There are two kinds of projects that might get impacted. Third-party
> > > > > ports, I guess they will just accept moving to GPL3+.
> > > >
> > > > Yes. Or they keep on 3.25.x. But I hope the long term goal of any
> > > > third-party port would be to eventually get included upstream. Although
> > > > I admit we have at times been really slow incorporating new ports.
> > > >
> > > > >  Then there is VEX.
> > > > > The main project that I know of is PyVEX
> > https://github.com/angr/pyvex
> > > > > which seems to be under a BSD licence. That looks wrong to me to
> > start with.
> > > >
> > > > I think that is not deliberately wrong, just slightly confused. They
> > > > should probably mention top-level that they are (re)distributing
> > > > various parts under the GPL (see e.g. the pyvex_c and vex subdirs,
> > > > which properly carry GPL notices). Which means the project as a whole
> > > > also is distributed GPL, even if parts of the source code could also be
> > > > reused under the BSD license as long as it isn't derived from the GPL
> > > > parts.
> > >
> > > Sounds like everyone is OK with this in principle, right?
> > >
> > > FWIW, I'd like that too.  For s390x it would certainly simplify things
> > > quite a bit.
> >
> > Yes, it sounds like we have concensus. I'll contact the FSF legal team
> > to ask if they have any comments/advise and then update the headers
> > based on their feedback.
> >
> > Thanks,
> >
> > Mark
> >
> >
> > _______________________________________________
> > Valgrind-developers mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-developers
> >

Re: [Valgrind-developers] Switching to GPLv3+ for next release (Was: Using objdump code for disassembly)

[Nicholas N. <n.n...@gm...>]

Hi,

I don't agree with the license update. At least, not without more
discussion.

The motivation seemed to be about replacing Valgrind's disassembly code
with some third-party code. Which sounds like an enormously large and
invasive change.

And the license discussion hasn't gotten any deeper than "that might be
nice". License changes are serious, they should be taken seriously.

Nick


On Tue, 17 Jun 2025 at 02:53, Mark Wielaard <ma...@kl...> wrote:

> Hi all,
>
> Updating the subject to be explicit about the goal.
>
> On Thu, 2025-06-12 at 15:21 +0200, Andreas Arnez wrote:
> > On Mon, Jun 02 2025, Mark Wielaard wrote:
> > > On Sun, 2025-06-01 at 17:47 +0200, Paul Floyd wrote:
> > > > On 6/1/25 15:22, Mark Wielaard wrote:
> > > > > I think an upgrade to GPLv3+ for valgrind is a good idea. It would
> > > > > also allow us to upgrade some gdbserver parts (various files under
> > > > > coregrind/m_gdbserver). Note that the new vgstack utility is
> already
> > > > > derived from GPLv3+ code.
> > > > >
> > > > > We could make that a goal for 3.26.0 (or maybe that deserves
> finally
> > > > > going to 4.0?) for our October release. I can contact the FSF legal
> > > > > team to ask if they want to help with or see any issues with such
> an
> > > > > upgrade if we want to incorporate more GPLv3+ code from the core
> > > > > toolchain projects.
> > > >
> > > > Licence-wise, I don't have much of an opinion. It would be nice to
> be
> > > > able to integrate code more easily.
> > > >
> > > > There are two kinds of projects that might get impacted. Third-party
> > > > ports, I guess they will just accept moving to GPL3+.
> > >
> > > Yes. Or they keep on 3.25.x. But I hope the long term goal of any
> > > third-party port would be to eventually get included upstream. Although
> > > I admit we have at times been really slow incorporating new ports.
> > >
> > > >  Then there is VEX.
> > > > The main project that I know of is PyVEX
> https://github.com/angr/pyvex
> > > > which seems to be under a BSD licence. That looks wrong to me to
> start with.
> > >
> > > I think that is not deliberately wrong, just slightly confused. They
> > > should probably mention top-level that they are (re)distributing
> > > various parts under the GPL (see e.g. the pyvex_c and vex subdirs,
> > > which properly carry GPL notices). Which means the project as a whole
> > > also is distributed GPL, even if parts of the source code could also be
> > > reused under the BSD license as long as it isn't derived from the GPL
> > > parts.
> >
> > Sounds like everyone is OK with this in principle, right?
> >
> > FWIW, I'd like that too.  For s390x it would certainly simplify things
> > quite a bit.
>
> Yes, it sounds like we have concensus. I'll contact the FSF legal team
> to ask if they have any comments/advise and then update the headers
> based on their feedback.
>
> Thanks,
>
> Mark
>
>
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>

Re: [Valgrind-developers] Switching to GPLv3+ for next release (Was: Using objdump code for disassembly)

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

Hi Julian,

On Mon, Jun 16, 2025 at 07:14:14PM +0200, Julian Seward wrote:
> 
> Sorry to reply so late to this.

No worries. It isn't that urgent. Just making sure we are all on the
same page. Happy I changed the subject to attract your attention :)

> I currently don't have much of an opinion about GPL 2(+) vs 3(+);
> from looking at the Wikipedia page it sounds like GPL 3 does fix
> some problems in GPL 2.

Yeah, I found the following a nice overview:
https://www.gnu.org/licenses/quick-guide-gplv3.html

> I'm unclear about whether it's possible to change the license without every
> contributor's agreement.  I had the impression that it would indeed require
> the consent of all authors.  If that is true I would think it would be a
> significant difficulty, since there are literally dozens, if not more, of
> authors.

It is my understanding that as long as those authors contributed under
"either version 2 of the License, or (at your option) any later
version" then anybody is allowed to upgrade. Because they already gave
that permission. This is also what our manual says:
https://valgrind.org/docs/manual/manual-intro.html

    If you contribute code to Valgrind, please ensure your
    contributions are licensed as "GPLv2, or (at your option) any
    later version."  This is so as to allow the possibility of easily
    upgrading the license to GPLv3 in future.

BTW. You wrote that part, so I think in the past you already thought
about this :)

> Also, some of the code for the kernel interface is derived from Linux kernel
> sources (see comment at include/vki/vki-linux.h:29), which would seem to mean
> that changing it away from GPL 2 isn't possible.

Yes, that is one of the things I want to ask FSF legal about. It is my
understanding that the use of constants and simple structure
definitions, typedefs, etc from these header files doesn't create a
derivative work. There is a Linux-syscall-note that implies that for
the UAPI headers that we used to create the vki files (since they are
the same constants and type definitions used for normal user space
programs to make syscalls, just name slightly differently). But it
would be good to have a more concrete statement.

There are also some test cases derived from the qemu testsuite that
are explicitly GPLv2-only. But I think we can just leave those GPLv2
since they are separate works.

I'll CC you on my FSF legal questions.

Cheers,

Mark

Re: [Valgrind-developers] Switching to GPLv3+ for next release (Was: Using objdump code for disassembly)

[Julian S. <jse...@gm...>]

Sorry to reply so late to this.

I currently don't have much of an opinion about GPL 2(+) vs 3(+); from looking
at the Wikipedia page it sounds like GPL 3 does fix some problems in GPL 2.

I'm unclear about whether it's possible to change the license without every
contributor's agreement.  I had the impression that it would indeed require
the consent of all authors.  If that is true I would think it would be a
significant difficulty, since there are literally dozens, if not more, of
authors.

Also, some of the code for the kernel interface is derived from Linux kernel
sources (see comment at include/vki/vki-linux.h:29), which would seem to mean
that changing it away from GPL 2 isn't possible.

J

On 16/06/2025 18:52, Mark Wielaard wrote:
> Hi all,
> 
> Updating the subject to be explicit about the goal.
> 
> On Thu, 2025-06-12 at 15:21 +0200, Andreas Arnez wrote:
>> On Mon, Jun 02 2025, Mark Wielaard wrote:
>>> On Sun, 2025-06-01 at 17:47 +0200, Paul Floyd wrote:
>>>> On 6/1/25 15:22, Mark Wielaard wrote:
>>>>> I think an upgrade to GPLv3+ for valgrind is a good idea. It would
>>>>> also allow us to upgrade some gdbserver parts (various files under
>>>>> coregrind/m_gdbserver). Note that the new vgstack utility is already
>>>>> derived from GPLv3+ code.
>>>>>
>>>>> We could make that a goal for 3.26.0 (or maybe that deserves finally
>>>>> going to 4.0?) for our October release. I can contact the FSF legal
>>>>> team to ask if they want to help with or see any issues with such an
>>>>> upgrade if we want to incorporate more GPLv3+ code from the core
>>>>> toolchain projects.
>>>>
>>>> Licence-wise, I don't have much of an opinion. It would be nice to be
>>>> able to integrate code more easily.
>>>>
>>>> There are two kinds of projects that might get impacted. Third-party
>>>> ports, I guess they will just accept moving to GPL3+.
>>>
>>> Yes. Or they keep on 3.25.x. But I hope the long term goal of any
>>> third-party port would be to eventually get included upstream. Although
>>> I admit we have at times been really slow incorporating new ports.
>>>
>>>>   Then there is VEX.
>>>> The main project that I know of is PyVEX https://github.com/angr/pyvex
>>>> which seems to be under a BSD licence. That looks wrong to me to start with.
>>>
>>> I think that is not deliberately wrong, just slightly confused. They
>>> should probably mention top-level that they are (re)distributing
>>> various parts under the GPL (see e.g. the pyvex_c and vex subdirs,
>>> which properly carry GPL notices). Which means the project as a whole
>>> also is distributed GPL, even if parts of the source code could also be
>>> reused under the BSD license as long as it isn't derived from the GPL
>>> parts.
>>
>> Sounds like everyone is OK with this in principle, right?
>>
>> FWIW, I'd like that too.  For s390x it would certainly simplify things
>> quite a bit.
> 
> Yes, it sounds like we have concensus. I'll contact the FSF legal team
> to ask if they have any comments/advise and then update the headers
> based on their feedback.
> 
> Thanks,
> 
> Mark

[Valgrind-developers] Switching to GPLv3+ for next release (Was: Using objdump code for disassembly)

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

Hi all,

Updating the subject to be explicit about the goal.

On Thu, 2025-06-12 at 15:21 +0200, Andreas Arnez wrote:
> On Mon, Jun 02 2025, Mark Wielaard wrote:
> > On Sun, 2025-06-01 at 17:47 +0200, Paul Floyd wrote:
> > > On 6/1/25 15:22, Mark Wielaard wrote:
> > > > I think an upgrade to GPLv3+ for valgrind is a good idea. It would
> > > > also allow us to upgrade some gdbserver parts (various files under
> > > > coregrind/m_gdbserver). Note that the new vgstack utility is already
> > > > derived from GPLv3+ code.
> > > > 
> > > > We could make that a goal for 3.26.0 (or maybe that deserves finally
> > > > going to 4.0?) for our October release. I can contact the FSF legal
> > > > team to ask if they want to help with or see any issues with such an
> > > > upgrade if we want to incorporate more GPLv3+ code from the core
> > > > toolchain projects.
> > > 
> > > Licence-wise, I don't have much of an opinion. It would be nice to be 
> > > able to integrate code more easily.
> > > 
> > > There are two kinds of projects that might get impacted. Third-party 
> > > ports, I guess they will just accept moving to GPL3+.
> > 
> > Yes. Or they keep on 3.25.x. But I hope the long term goal of any
> > third-party port would be to eventually get included upstream. Although
> > I admit we have at times been really slow incorporating new ports.
> > 
> > >  Then there is VEX. 
> > > The main project that I know of is PyVEX https://github.com/angr/pyvex 
> > > which seems to be under a BSD licence. That looks wrong to me to start with.
> > 
> > I think that is not deliberately wrong, just slightly confused. They
> > should probably mention top-level that they are (re)distributing
> > various parts under the GPL (see e.g. the pyvex_c and vex subdirs,
> > which properly carry GPL notices). Which means the project as a whole
> > also is distributed GPL, even if parts of the source code could also be
> > reused under the BSD license as long as it isn't derived from the GPL
> > parts.
> 
> Sounds like everyone is OK with this in principle, right?
> 
> FWIW, I'd like that too.  For s390x it would certainly simplify things
> quite a bit.

Yes, it sounds like we have concensus. I'll contact the FSF legal team
to ask if they have any comments/advise and then update the headers
based on their feedback.

Thanks,

Mark

Re: [Valgrind-developers] Looking for a copy valgrind-solaris repository

[John P. A. G. <gla...@ph...>]

Hi,

On Sat, 2025-06-07 at 12:02 +0200, John Paul Adrian Glaubitz wrote:
> > The repo tarball contains a bare mercurial repo with 3 branches, default 
> > with linux-sparc64 and solaris-sparc64 (I haven't looked at the 3rd branch).
> > The code is 8 years old, merging changes from the official Valgrand repo 
> > is going to be quite a big job."
> > 
> > The above tarball seems to have the full history. My mercurial skills 
> > are very rusty, but I was able to clone the above repp. That gives me
> > 
> > paulf> hg identify
> > df5811b684c8 (solaris-sparc)
> > 
> > The final commit is
> > 
> > changeset:   2459:90e2aa4080b0
> > tag:         tip
> > parent:      2448:e5c9c8554fa6
> > user:        Ivo Raisr <iv...@iv...>
> > date:        Thu Aug 17 18:58:56 2017 +0000
> > summary:     Merge Valgrind r16465-16470 and VEX r3400
> > 
> > and the initial one
> > 
> > changeset:   0:69eafdcdbfa0
> > user:        Petr Pavlu <se...@da...>
> > date:        Fri Jul 29 16:25:15 2011 +0200
> > summary:     Import Valgrind r11954 and VEX r2186
> > 
> > 
> > I see 2460 changesets on that branch.
> 
> This is amazing! This is exactly what I was looking for but did not expect to get
> ever. I'm really blown away! Big thank you to everyone behind the mercurial archival
> project on Bitbucket!

I have imported the Mercurial repository into git now and pushed it to Github:

https://github.com/glaubitz/valgrind-sparc/tree/solaris-sparc-git

I have not rebased the code with upstream yet as this requires some elbow grease.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Valgrind-developers] Using objdump code for disassembly

[Andreas A. <ar...@li...>]

Hi Folks,

On Mon, Jun 02 2025, Mark Wielaard wrote:

> On Sun, 2025-06-01 at 17:47 +0200, Paul Floyd wrote:
>> On 6/1/25 15:22, Mark Wielaard wrote:
>> > I think an upgrade to GPLv3+ for valgrind is a good idea. It would
>> > also allow us to upgrade some gdbserver parts (various files under
>> > coregrind/m_gdbserver). Note that the new vgstack utility is already
>> > derived from GPLv3+ code.
>> > 
>> > We could make that a goal for 3.26.0 (or maybe that deserves finally
>> > going to 4.0?) for our October release. I can contact the FSF legal
>> > team to ask if they want to help with or see any issues with such an
>> > upgrade if we want to incorporate more GPLv3+ code from the core
>> > toolchain projects.
>> 
>> Licence-wise, I don't have much of an opinion. It would be nice to be 
>> able to integrate code more easily.
>> 
>> There are two kinds of projects that might get impacted. Third-party 
>> ports, I guess they will just accept moving to GPL3+.
>
> Yes. Or they keep on 3.25.x. But I hope the long term goal of any
> third-party port would be to eventually get included upstream. Although
> I admit we have at times been really slow incorporating new ports.
>
>>  Then there is VEX. 
>> The main project that I know of is PyVEX https://github.com/angr/pyvex 
>> which seems to be under a BSD licence. That looks wrong to me to start with.
>
> I think that is not deliberately wrong, just slightly confused. They
> should probably mention top-level that they are (re)distributing
> various parts under the GPL (see e.g. the pyvex_c and vex subdirs,
> which properly carry GPL notices). Which means the project as a whole
> also is distributed GPL, even if parts of the source code could also be
> reused under the BSD license as long as it isn't derived from the GPL
> parts.

Sounds like everyone is OK with this in principle, right?

FWIW, I'd like that too.  For s390x it would certainly simplify things
quite a bit.


-- 
Andreas

Re: [Valgrind-developers] headaches abound.. platform support

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

On 6/10/25 07:56, Tom Hughes via Valgrind-developers wrote:
> On 10/06/2025 00:30, John Reiser wrote:
>>> It looks like just about every platform except alpha is supported, 
>>> so how much work is it to get a new platform supported (not sure how 
>>> much needs to be added/modified)?
>>
>> Choose a supported $ARCH with 64-bit words and fixed-width instructions:
>>
>>     $ grep -i arm64 $(find valgrind -name '*.[ch]')  |  wc -l
>>     5214
>>
>
> That's also a serious underestimate as there are whole files that
> are processor specific, like the basic CPU emulation:
>

Even counting for the fact that amd64 has probably more instructions 
than arm64, in VEX I see

$ cloc *arm64*c *arm64*h

github.com/AlDanial/cloc v 2.04  T=0.04 s (153.5 files/s, 800954.5 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment 
           code
-------------------------------------------------------------------------------
C                                4           2113           5552 
          22130
C/C++ Header                     2            157            282 
           1072
-------------------------------------------------------------------------------
SUM:                             6           2270           5834 
          23202
-------------------------------------------------------------------------------

You will need to know the Alpha Reference Manual inside-out (about 1000 
pages). If you are not already an expert in Alpha machine code then you 
will need to be very dedicated and be willing to spend a substantial 
amount of time working in it.

For reference, much of the Solaris amd64 port was does done for a 
masters thesis (typically 1 year). And that didn't require adding amd64 
support.

Then there's the regression tests. We have over 100 amd64 tests. arm64 
is a bit weak, we only have 20 tests. Several of these are huge tests 
that use a python script to generate extensive coverage for opcodes with 
different register/memory modes.

A+

Paul

Re: [Valgrind-developers] headaches abound.. platform support

[Tom H. <to...@co...>]

On 10/06/2025 00:30, John Reiser wrote:
>> It looks like just about every platform except alpha is supported, so 
>> how much work is it to get a new platform supported (not sure how much 
>> needs to be added/modified)?
> 
> Choose a supported $ARCH with 64-bit words and fixed-width instructions:
> 
>     $ grep -i arm64 $(find valgrind -name '*.[ch]')  |  wc -l
>     5214
> 
> So that's an estimate of how much you have to add/modify.
> Of course not all of it must be done "by hand", but still
> there probably are a couple thousand lines of code.

That's also a serious underestimate as there are whole files that
are processor specific, like the basic CPU emulation:

     595 VEX/priv/guest_amd64_defs.h
    4938 VEX/priv/guest_amd64_helpers.c
   32801 VEX/priv/guest_amd64_toIR.c
    4344 VEX/priv/host_amd64_defs.c
     875 VEX/priv/host_amd64_defs.h
    5461 VEX/priv/host_amd64_isel.c
   49014 total

and OS interfaces:

   319 coregrind/m_dispatch/dispatch-amd64-linux.S
   606 coregrind/m_sigframe/sigframe-amd64-linux.c
   253 coregrind/m_syswrap/syscall-amd64-linux.S
   915 coregrind/m_syswrap/syswrap-amd64-linux.c
  2093 total

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-developers] headaches abound.. platform support

[John P. A. G. <gla...@ph...>]

Hi Greg,

On Mon, 2025-06-09 at 14:35 -0700, Greg Chandler wrote:
> I'm trying to troubleshoot a very massive headache with the gcc driver 
> on alpha, so I gave this a shot and found out the platform isn't 
> supported.
> I can find no listing of what is and isn't suported outside of the 
> configure script itself. (Should maybe be in the FAQ?)
> 
> It looks like just about every platform except alpha is supported, so 
> how much work is it to get a new platform supported (not sure how much 
> needs to be added/modified)?

Adding support for a new architecture is usually not trivial, so someone
will have to dedicate quite some work for it. For that reason, it's unlikely
that historic (retro) platforms such as Alpha are going to be supported in
the near future - unless someone finds a way to have AI's write the code.

There are more architectures such as PA-RISC, Motorola 68k, SuperH and SPARC
that are currently not supported by Valgrind either, so it's not just Alpha.

I'm maintaining Debian on old and exotic architectures in Debian Ports and
if you're actively working on Alpha, it would be great if you could join our
IRC channel (#debian-ports on OFTC).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Valgrind-developers] headaches abound.. platform support

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

> It looks like just about every platform except alpha is supported, so 
> how much work is it to get a new platform supported (not sure how much 
> needs to be added/modified)?

Choose a supported $ARCH with 64-bit words and fixed-width instructions:

    $ grep -i arm64 $(find valgrind -name '*.[ch]')  |  wc -l
    5214

So that's an estimate of how much you have to add/modify.
Of course not all of it must be done "by hand", but still
there probably are a couple thousand lines of code.

[Valgrind-developers] headaches abound.. platform support

[Greg C. <cha...@wi...>]

I'm trying to troubleshoot a very massive headache with the gcc driver 
on alpha, so I gave this a shot and found out the platform isn't 
supported.
I can find no listing of what is and isn't suported outside of the 
configure script itself. (Should maybe be in the FAQ?)

It looks like just about every platform except alpha is supported, so 
how much work is it to get a new platform supported (not sure how much 
needs to be added/modified)?


/tmp/valgrind-3.25.1# ./configure --host=alpha-linux-gnu 
--target=alpha-linux-gnu
checking for a BSD-compatible install... /usr/bin/ginstall -c
checking whether sleep supports fractional seconds... yes
checking filesystem timestamp resolution... 0.01
checking whether build environment is sane... yes
checking for alpha-linux-gnu-strip... alpha-linux-gnu-strip
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking xargs -n works... yes
checking whether to enable maintainer-specific portions of Makefiles... 
no
checking whether ln -s works... yes
checking for alpha-linux-gnu-gcc... alpha-linux-gnu-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether alpha-linux-gnu-gcc accepts -g... yes
checking for alpha-linux-gnu-gcc option to enable C11 features... none 
needed
checking whether alpha-linux-gnu-gcc understands -c and -o together... 
yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of alpha-linux-gnu-gcc... gcc3
checking how to run the C preprocessor... alpha-linux-gnu-gcc -E
checking for alpha-linux-gnu-g++... alpha-linux-gnu-g++
checking whether the compiler supports GNU C++... yes
checking whether alpha-linux-gnu-g++ accepts -g... yes
checking for alpha-linux-gnu-g++ option to enable C++11 features... none 
needed
checking dependency style of alpha-linux-gnu-g++... gcc3
checking for alpha-linux-gnu-ranlib... alpha-linux-gnu-ranlib
checking for gcc-ranlib... /usr/bin/gcc-ranlib
checking for a sed that does not truncate output... /usr/bin/sed
checking for gsha256sum... no
checking for sha256sum... sha256sum
checking for ar... /usr/bin/ar
checking for gcc-ar... /usr/bin/gcc-ar
checking for perl... /usr/bin/perl
checking for gdb... /usr/bin/gdb
checking dependency style of alpha-linux-gnu-gcc... gcc3
checking for diff -u... yes
checking for a supported version of gcc... ok (14.2.0)
checking build system type... x86_64-pc-linux-gnu
checking host system type... alpha-unknown-linux-gnu
checking for a supported CPU... no (alpha)
configure: error: Unsupported host architecture. Sorry

[Valgrind-developers] [valgrind] s390x: Fix thinko, remove a few fixs390's

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

https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=67e6e1c4c2fa7847ab7cb14360814599520932c6

commit 67e6e1c4c2fa7847ab7cb14360814599520932c6
Author: Florian Krohm <fl...@ei...>
Date:   Sat Jun 7 12:12:56 2025 +0000

    s390x: Fix thinko, remove a few fixs390's
    
    All of VEX's Iops are side effect free. They don't set the condition
    code. Therefore, when emitting a VCEQ, VPK[L]S or VCH[L] the 'set cc' field
    is 0. Nothing to fix here.

Diff:
---
 VEX/priv/host_s390_defs.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/VEX/priv/host_s390_defs.c b/VEX/priv/host_s390_defs.c
index e26ea09d48..08a34a5fa9 100644
--- a/VEX/priv/host_s390_defs.c
+++ b/VEX/priv/host_s390_defs.c
@@ -5813,7 +5813,6 @@ static UChar*
 s390_emit_VCEQ(UChar *p, UChar v1, UChar v2, UChar v3, UChar m4)
 {
    if (UNLIKELY(vex_traceflags & VEX_TRACE_ASM))
-      /* fixs390: m5 = 0  --> condition code not set */
       S390_DISASM(XMNM("vceq", vch_like_disasm), VR(v1), VR(v2), VR(v3), MASK(m4), MASK(0));
 
    return emit_VRR_VVVM(p, 0xE700000000f8ULL, v1, v2, v3, m4);
@@ -5844,7 +5843,6 @@ static UChar *
 s390_emit_VPKS(UChar *p, UChar v1, UChar v2, UChar v3, UChar m4)
 {
    if (UNLIKELY(vex_traceflags & VEX_TRACE_ASM))
-      /* fixs390: m5 = 0  --> condition code not set */
       S390_DISASM(XMNM("vpks", vch_like_disasm), VR(v1), VR(v2), VR(v3), MASK(m4), MASK(0));
 
    return emit_VRR_VVVM(p, 0xE70000000097ULL, v1, v2, v3, m4);
@@ -5855,7 +5853,6 @@ static UChar *
 s390_emit_VPKLS(UChar *p, UChar v1, UChar v2, UChar v3, UChar m4)
 {
    if (UNLIKELY(vex_traceflags & VEX_TRACE_ASM))
-      /* fixs390: m5 = 0  --> condition code not set */
       S390_DISASM(XMNM("vpkls", vch_like_disasm), VR(v1), VR(v2), VR(v3), MASK(m4), MASK(0));
 
    return emit_VRR_VVVM(p, 0xE70000000095ULL, v1, v2, v3, m4);
@@ -5952,7 +5949,6 @@ static UChar *
 s390_emit_VCH(UChar *p, UChar v1, UChar v2, UChar v3, UChar m4)
 {
    if (UNLIKELY(vex_traceflags & VEX_TRACE_ASM))
-      /* fixs390: m5 = 0  --> condition code not set */
       S390_DISASM(XMNM("vch", vch_like_disasm), VR(v1), VR(v2), VR(v3), MASK(m4), MASK(0));
 
    return emit_VRR_VVVM(p, 0xE700000000fbULL, v1, v2, v3, m4);
@@ -5962,7 +5958,6 @@ static UChar *
 s390_emit_VCHL(UChar *p, UChar v1, UChar v2, UChar v3, UChar m4)
 {
    if (UNLIKELY(vex_traceflags & VEX_TRACE_ASM))
-      /* fixs390: m5 = 0  --> condition code not set */
       S390_DISASM(XMNM("vchl", vch_like_disasm), VR(v1), VR(v2), VR(v3), MASK(m4), MASK(0));
 
    return emit_VRR_VVVM(p, 0xE700000000f9ULL, v1, v2, v3, m4);

[Valgrind-developers] [valgrind] s390x: Improve none/tests/s390x/cvb.c

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

https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=aa28efc1a9c7ac6ffb081f8fa40b17b29d04bf98

commit aa28efc1a9c7ac6ffb081f8fa40b17b29d04bf98
Author: Florian Krohm <fl...@ei...>
Date:   Sat Jun 7 11:48:01 2025 +0000

    s390x: Improve none/tests/s390x/cvb.c
    
    The result of a CVB insn resides in an 8-byte register of which the
    most significant 4 bytes ought to unchanged by the insn. We want to
    check that. So we need to use a variable of type 'long'.
    Rewrite the code a bit.

Diff:
---
 none/tests/s390x/cvb.c          | 165 ++++++++++++++++++----------------------
 none/tests/s390x/cvb.stdout.exp | 150 +++++++++++++++++++-----------------
 2 files changed, 157 insertions(+), 158 deletions(-)

diff --git a/none/tests/s390x/cvb.c b/none/tests/s390x/cvb.c
index ce5f9e405c..3f928a6b21 100644
--- a/none/tests/s390x/cvb.c
+++ b/none/tests/s390x/cvb.c
@@ -1,104 +1,89 @@
+#include <assert.h>
 #include <stdio.h>
 
-static unsigned long test[] ={
-	0x000000000000000a,
-	0x000000000000001a,
-	0x000000000000012a,
-	0x000000000000123a,
-	0x000000000001234a,
-	0x000000000012345a,
-	0x000000000123456a,
-	0x000000001234567a,
-	0x000000012345678a,
-	0x000000123456789a,
-	0x000001234567890a,
-	0x000000000000000b,
-	0x000000000000001b,
-	0x000000000000012b,
-	0x000000000000123b,
-	0x000000000001234b,
-	0x000000000012345b,
-	0x000000000123456b,
-	0x000000001234567b,
-	0x000000012345678b,
-	0x000000123456789b,
-	0x000001234567890b,
-	0x000000000000000c,
-	0x000000000000001c,
-	0x000000000000012c,
-	0x000000000000123c,
-	0x000000000001234c,
-	0x000000000012345c,
-	0x000000000123456c,
-	0x000000001234567c,
-	0x000000012345678c,
-	0x000000123456789c,
-	0x000001234567890c,
-	0x000000000000000d,
-	0x000000000000001d,
-	0x000000000000012d,
-	0x000000000000123d,
-	0x000000000001234d,
-	0x000000000012345d,
-	0x000000000123456d,
-	0x000000001234567d,
-	0x000000012345678d,
-	0x000000123456789d,
-	0x000001234567890d,
-	0x000000000000000e,
-	0x000000000000001e,
-	0x000000000000012e,
-	0x000000000000123e,
-	0x000000000001234e,
-	0x000000000012345e,
-	0x000000000123456e,
-	0x000000001234567e,
-	0x000000012345678e,
-	0x000000123456789e,
-	0x000001234567890e,
-	0x000000000000000f,
-	0x000000000000001f,
-	0x000000000000012f,
-	0x000000000000123f,
-	0x000000000001234f,
-	0x000000000012345f,
-	0x000000000123456f,
-	0x000000001234567f,
-	0x000000012345678f,
-	0x000000123456789f,
-	0x000001234567890f,
-        /* min and max */
-	0x000002147483647c,
-	0x000002147483648d,
-
-/* fixs390: we also need to check if invalid values cause a fixed-point-devide exception.
-   Not yet implemented. */
-/*	0x000002147483648c,
-	0x000002147483649d,
-	0x00000000000000fa, */
-
+/* Valid values (excluding sign code) */
+static const unsigned long valid[] = {
+   0x0000000000000000,
+   0x0000000000000010,
+   0x0000000000000120,
+   0x0000000000001230,
+   0x0000000000012340,
+   0x0000000000123450,
+   0x0000000001234560,
+   0x0000000012345670,
+   0x0000000123456780,
+   0x0000001234567890,
+   0x0000012345678900,
 };
 
+/* Boundary values (excluding sign code) */
+static const unsigned long max = 0x0000021474836470;
+static const unsigned long min = 0x0000021474836480;
+
+/* Valid sign codes */
+static const unsigned sign_code_pos[] = { 0xa, 0xc, 0xe, 0xf };
+static const unsigned sign_code_neg[] = { 0xb, 0xd };
+
+#define NUM_EL(x)   (sizeof(x) / sizeof(*(x)))
 
-static signed int dec_to_hex(unsigned long *addr)
+/* The value pointed to by ADDR is valid including sign code. */
+static signed int
+dec_to_hex(unsigned long *addr)
 {
-        register signed int res asm("2") = 0;
-        register unsigned long *_addr asm("4") = addr;
+   long res;
+   int res1, res2;
 
-        asm volatile(
-        "       cvb %0,0(0,%1)"
-                : "=d" (res) : "d" (_addr) : "memory");
-        return res & 0xffffffff;
-}
+   res = 0;
+   asm volatile("cvb %0,0(0,%1)"
+                : "+d" (res) : "a" (addr) : "memory");
+
+   // bits [0:31] ought to be unchanged
+   // Catch bits that are set but shouldn't be
+   assert((res >> 32) == 0);
+   res1 = (int)res;
 
+   res = -1;
+   asm volatile("cvb %0,0(0,%1)"
+                : "+d" (res) : "a" (addr) : "memory");
 
+   // bits [0:31] ought to be unchanged
+   // Catch bits that are cleared but shouldn't be
+   assert((res >> 32) == -1);
+   res2 = (int)(res & 0xffffffff);
 
+   // Successful conversion
+   assert(res1 == res2);
 
-int main()
+   return res1;
+}
+
+int main(void)
 {
-	int i;
+   for (int sign_code = 0xa; sign_code <= 0xf; ++sign_code) {
+      printf("Testing in-range values with sign code 0x%x\n", sign_code);
+      for (int i = 0; i < NUM_EL(valid); ++i) {
+         unsigned long value = valid[i] | sign_code;
+         printf("0x%016lx  -->  %d\n", value, dec_to_hex(&value));
+      }
+   }
+   printf("\n");
+
+   printf("Testing max. value 0x%lx\n", max >> 4);
+   for (int i = 0; i < NUM_EL(sign_code_pos); ++i) {
+      unsigned sign_code = sign_code_pos[i];
+      unsigned long value = max | sign_code;
+      printf("0x%016lx  -->  %d\n", value, dec_to_hex(&value));
+   }
+   printf("\n");
+
+   printf("Testing min. value 0x%lx\n", min >> 4);
+   for (int i = 0; i < NUM_EL(sign_code_neg); ++i) {
+      unsigned sign_code = sign_code_neg[i];
+      unsigned long value = min | sign_code;
+      printf("0x%016lx  -->  %d\n", value, dec_to_hex(&value));
+   }
+
+   /* fixs390: check behaviour for invalid values, out-of-range values and values with invalid sign code */
 
-	for (i = 0; i < sizeof(test) / sizeof(test[0]); i++)
-	printf("%d\n", dec_to_hex(&test[i]));
-	return 0;
+   return 0;
 }
diff --git a/none/tests/s390x/cvb.stdout.exp b/none/tests/s390x/cvb.stdout.exp
index 35d6a600fe..268ea354d2 100644
--- a/none/tests/s390x/cvb.stdout.exp
+++ b/none/tests/s390x/cvb.stdout.exp
@@ -1,68 +1,82 @@
-0
-1
-12
-123
-1234
-12345
-123456
-1234567
-12345678
-123456789
-1234567890
-0
--1
--12
--123
--1234
--12345
--123456
--1234567
--12345678
--123456789
--1234567890
-0
-1
-12
-123
-1234
-12345
-123456
-1234567
-12345678
-123456789
-1234567890
-0
--1
--12
--123
--1234
--12345
--123456
--1234567
--12345678
--123456789
--1234567890
-0
-1
-12
-123
-1234
-12345
-123456
-1234567
-12345678
-123456789
-1234567890
-0
-1
-12
-123
-1234
-12345
-123456
-1234567
-12345678
-123456789
-1234567890
-2147483647
--2147483648
+Testing in-range values with sign code 0xa
+0x000000000000000a  -->  0
+0x000000000000001a  -->  1
+0x000000000000012a  -->  12
+0x000000000000123a  -->  123
+0x000000000001234a  -->  1234
+0x000000000012345a  -->  12345
+0x000000000123456a  -->  123456
+0x000000001234567a  -->  1234567
+0x000000012345678a  -->  12345678
+0x000000123456789a  -->  123456789
+0x000001234567890a  -->  1234567890
+Testing in-range values with sign code 0xb
+0x000000000000000b  -->  0
+0x000000000000001b  -->  -1
+0x000000000000012b  -->  -12
+0x000000000000123b  -->  -123
+0x000000000001234b  -->  -1234
+0x000000000012345b  -->  -12345
+0x000000000123456b  -->  -123456
+0x000000001234567b  -->  -1234567
+0x000000012345678b  -->  -12345678
+0x000000123456789b  -->  -123456789
+0x000001234567890b  -->  -1234567890
+Testing in-range values with sign code 0xc
+0x000000000000000c  -->  0
+0x000000000000001c  -->  1
+0x000000000000012c  -->  12
+0x000000000000123c  -->  123
+0x000000000001234c  -->  1234
+0x000000000012345c  -->  12345
+0x000000000123456c  -->  123456
+0x000000001234567c  -->  1234567
+0x000000012345678c  -->  12345678
+0x000000123456789c  -->  123456789
+0x000001234567890c  -->  1234567890
+Testing in-range values with sign code 0xd
+0x000000000000000d  -->  0
+0x000000000000001d  -->  -1
+0x000000000000012d  -->  -12
+0x000000000000123d  -->  -123
+0x000000000001234d  -->  -1234
+0x000000000012345d  -->  -12345
+0x000000000123456d  -->  -123456
+0x000000001234567d  -->  -1234567
+0x000000012345678d  -->  -12345678
+0x000000123456789d  -->  -123456789
+0x000001234567890d  -->  -1234567890
+Testing in-range values with sign code 0xe
+0x000000000000000e  -->  0
+0x000000000000001e  -->  1
+0x000000000000012e  -->  12
+0x000000000000123e  -->  123
+0x000000000001234e  -->  1234
+0x000000000012345e  -->  12345
+0x000000000123456e  -->  123456
+0x000000001234567e  -->  1234567
+0x000000012345678e  -->  12345678
+0x000000123456789e  -->  123456789
+0x000001234567890e  -->  1234567890
+Testing in-range values with sign code 0xf
+0x000000000000000f  -->  0
+0x000000000000001f  -->  1
+0x000000000000012f  -->  12
+0x000000000000123f  -->  123
+0x000000000001234f  -->  1234
+0x000000000012345f  -->  12345
+0x000000000123456f  -->  123456
+0x000000001234567f  -->  1234567
+0x000000012345678f  -->  12345678
+0x000000123456789f  -->  123456789
+0x000001234567890f  -->  1234567890
+
+Testing max. value 0x2147483647
+0x000002147483647a  -->  2147483647
+0x000002147483647c  -->  2147483647
+0x000002147483647e  -->  2147483647
+0x000002147483647f  -->  2147483647
+
+Testing min. value 0x2147483648
+0x000002147483648b  -->  -2147483648
+0x000002147483648d  -->  -2147483648

Re: [Valgrind-developers] Looking for a copy valgrind-solaris repository

[John P. A. G. <gla...@ph...>]

Hi Paul,

On Fri, 2025-06-06 at 19:53 +0200, Paul Floyd via Valgrind-developers wrote:
> I was recently contacted by Klaus Ziegler about this. Maybe you could 
> join forces?

The name sounds familiar but currently doesn't ring a bell. I will reach
out nevertheless. Thanks for the pointer.

> Here is part of the reply that I sent him:
> 
> "Work was done on a SPARC port by Sun, but it got dropped after the 
> Oracle takeover. A bit of a shame as the port was more or less complete 
> as far as I know. There is a copy of the bitbucket repo here:
> 
> https://bitbucket-archive.softwareheritage.org/projects/ir/iraisr/valgrind-solaris.html

The port was actually actively maintained until 2017 long after Oracle had
acquired Sun. Ivo gave a talk about his work at FOSDEM 2017 and I actually
attended his talk myelf.

See: https://archive.fosdem.org/2017/schedule/event/valgrind_sparcv9/

> The repo tarball contains a bare mercurial repo with 3 branches, default 
> with linux-sparc64 and solaris-sparc64 (I haven't looked at the 3rd branch).
> The code is 8 years old, merging changes from the official Valgrand repo 
> is going to be quite a big job."
> 
> The above tarball seems to have the full history. My mercurial skills 
> are very rusty, but I was able to clone the above repp. That gives me
> 
> paulf> hg identify
> df5811b684c8 (solaris-sparc)
> 
> The final commit is
> 
> changeset:   2459:90e2aa4080b0
> tag:         tip
> parent:      2448:e5c9c8554fa6
> user:        Ivo Raisr <iv...@iv...>
> date:        Thu Aug 17 18:58:56 2017 +0000
> summary:     Merge Valgrind r16465-16470 and VEX r3400
> 
> and the initial one
> 
> changeset:   0:69eafdcdbfa0
> user:        Petr Pavlu <se...@da...>
> date:        Fri Jul 29 16:25:15 2011 +0200
> summary:     Import Valgrind r11954 and VEX r2186
> 
> 
> I see 2460 changesets on that branch.

This is amazing! This is exactly what I was looking for but did not expect to get
ever. I'm really blown away! Big thank you to everyone behind the mercurial archival
project on Bitbucket!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Valgrind-developers] Looking for a copy valgrind-solaris repository

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

On 6/5/25 17:27, John Paul Adrian Glaubitz wrote:
> Hi,
>
> there used to be an out-of-tree port of Valgrind for Solaris SPARC by
> Ivo Raisr et al. that he talked about at FOSDEM [1].
>
> The repository was hosted on Bitbucket but the repository has been taken
> down, unfortunately [2].
>
> Does anyone have a copy of that repository including the commit history
> by any chance?
>
> I did find repository snapshots in the form of tarballs on archive.org,
> but these are missing the commit history. I would like to have the real
> repository though to be able to extract the patches and reapply them against
> the current upstream sources.

Hi Adrian

I was recently contacted by Klaus Ziegler about this. Maybe you could 
join forces?

Here is part of the reply that I sent him:

"Work was done on a SPARC port by Sun, but it got dropped after the 
Oracle takeover. A bit of a shame as the port was more or less complete 
as far as I know. There is a copy of the bitbucket repo here:

https://bitbucket-archive.softwareheritage.org/projects/ir/iraisr/valgrind-solaris.html

The repo tarball contains a bare mercurial repo with 3 branches, default 
with linux-sparc64 and solaris-sparc64 (I haven't looked at the 3rd branch).
The code is 8 years old, merging changes from the official Valgrand repo 
is going to be quite a big job."

The above tarball seems to have the full history. My mercurial skills 
are very rusty, but I was able to clone the above repp. That gives me

paulf> hg identify
df5811b684c8 (solaris-sparc)

The final commit is

changeset:   2459:90e2aa4080b0
tag:         tip
parent:      2448:e5c9c8554fa6
user:        Ivo Raisr <iv...@iv...>
date:        Thu Aug 17 18:58:56 2017 +0000
summary:     Merge Valgrind r16465-16470 and VEX r3400

and the initial one

changeset:   0:69eafdcdbfa0
user:        Petr Pavlu <se...@da...>
date:        Fri Jul 29 16:25:15 2011 +0200
summary:     Import Valgrind r11954 and VEX r2186


I see 2460 changesets on that branch.

Regards
Paul

[Valgrind-developers] Looking for a copy valgrind-solaris repository

[John P. A. G. <gla...@ph...>]

Hi,

there used to be an out-of-tree port of Valgrind for Solaris SPARC by
Ivo Raisr et al. that he talked about at FOSDEM [1].

The repository was hosted on Bitbucket but the repository has been taken
down, unfortunately [2].

Does anyone have a copy of that repository including the commit history
by any chance?

I did find repository snapshots in the form of tarballs on archive.org,
but these are missing the commit history. I would like to have the real
repository though to be able to extract the patches and reapply them against
the current upstream sources.

Thanks,
Adrian

> [1] https://archive.fosdem.org/2017/schedule/event/valgrind_sparcv9/
> [2] https://bitbucket.org/iraisr/valgrind-solaris

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[Valgrind-developers] [valgrind] ltp tests: Use new LTP 20250530, allow for filtering valgrind output

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

https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=b8891a4c5d139b8c327ee20c37066d601fc56b0a

commit b8891a4c5d139b8c327ee20c37066d601fc56b0a
Author: Martin Cermak <mc...@re...>
Date:   Tue Jun 3 13:43:18 2025 +0200

    ltp tests: Use new LTP 20250530, allow for filtering valgrind output
    
    Use fresh LTP 20250530.
    
    Allow for filtering valgrind output:
    
    In some cases the LTP tests intentionally work with SIGSEGV.  This
    happens e.g. with the mmap18 and select03 testcases.  Valgrind
    detects SIGSEGV and reports that as a failure.
    
    Such report can't be suppressed using the suppressions mechanism.
    That's why this update comes with "output filters". Filters are
    scripts that read from their stdin, and write filtered output to
    their stdout. Filters reside in auxprogs/filters.
    
    This update comes with 2 filters: For mmap18, and for select03.
    They are awk scripts.
    
    Except for filters, this update also blacklists testcase fork13
    because it is slow.  It is possible to add comments prefixed with
    the '#' sign (implicitly - because they don't match any testcase
    name), so a comment is added too.
    
    This update also introduces new default valgrind --vgdb=no switch. It
    improves valgrind behavior with nftw01 nftw6401 setfsgid04 setfsgid03_16
    and symlink03 testcases. These were previously complaining like this:
    
    ==22969== could not unlink /tmp/vgdb-pipe-from-vgdb-to-22969-by-root-on ...

Diff:
---
 auxprogs/Makefile.am      |  4 ++--
 auxprogs/filters/mmap18   | 29 +++++++++++++++++++++++++++++
 auxprogs/filters/select03 | 18 ++++++++++++++++++
 auxprogs/ltp-excludes.txt |  2 ++
 auxprogs/ltp-tester.sh    | 46 ++++++++++++++++++++++++++--------------------
 5 files changed, 77 insertions(+), 22 deletions(-)

diff --git a/auxprogs/Makefile.am b/auxprogs/Makefile.am
index 4a10fb1cf8..97eb9501eb 100644
--- a/auxprogs/Makefile.am
+++ b/auxprogs/Makefile.am
@@ -155,8 +155,8 @@ endif
 endif
 
 # Linux Test Project
-LTP_VERSION=20250130
-LTP_SHA256_SUM=02e4ec326be54c3fd92968229a468c02c665d168a8a673edc38a891f7395ae10
+LTP_VERSION=20250530
+LTP_SHA256_SUM=27586ba78eac1e40cd422add2842f1ad70f09fea55da3bd6a25e10feb786d4f2
 LTP_TAR_NAME=ltp-full-$(LTP_VERSION).tar.xz
 LTP_URL=https://github.com/linux-test-project/ltp/releases/download/$(LTP_VERSION)/$(LTP_TAR_NAME)
 LTP_TAR=$(AUX_CHECK_DIR)/$(LTP_TAR_NAME)
diff --git a/auxprogs/filters/mmap18 b/auxprogs/filters/mmap18
new file mode 100755
index 0000000000..edaf9c15d0
--- /dev/null
+++ b/auxprogs/filters/mmap18
@@ -0,0 +1,29 @@
+#!/bin/awk -f
+
+# Filter out stuff like the following, since it is expected output for the select03 testcase:
+
+# mmap18: unempty log2.filtered:
+# ==24613== 
+# ==24613== Process terminating with default action of signal 11 (SIGSEGV): dumping core
+# ==24613==  Access not within mapped region at address 0x4B3AFF8
+# ==24613==    at 0x401F86: check_depth_recursive (mmap18.c:118)
+# ==24613==  If you believe this happened as a result of a stack
+# ==24613==  overflow in your program's main thread (unlikely but
+# ==24613==  possible), you can try to increase the size of the
+# ==24613==  main thread stack using the --main-stacksize= flag.
+# ==24613==  The main thread stack size used in this run was 8388608.
+# ==24620== 
+# ==24620== Process terminating with default action of signal 11 (SIGSEGV): dumping core
+# ==24620==  Access not within mapped region at address 0x4B2EFF8
+# ==24620==    at 0x401F86: check_depth_recursive (mmap18.c:118)
+# ==24620==  If you believe this happened as a result of a stack
+# ==24620==  overflow in your program's main thread (unlikely but
+# ==24620==  possible), you can try to increase the size of the
+# ==24620==  main thread stack using the --main-stacksize= flag.
+# ==24620==  The main thread stack size used in this run was 8388608.
+
+skip = 0
+/==[0-9][0-9]*==/ { skip = 1 }
+/Process terminating with default action of signal 11/ { skip = 1; skipblock=1 }
+/The main thread stack size used in this run was/ { skip = 1; skipblock=0 }
+!skip && !skipblock { print }
diff --git a/auxprogs/filters/select03 b/auxprogs/filters/select03
new file mode 100755
index 0000000000..368a884e7c
--- /dev/null
+++ b/auxprogs/filters/select03
@@ -0,0 +1,18 @@
+#!/bin/awk -f
+
+# Filter out stuff like the following, since it is expected output for the select03 testcase:
+
+# ==22396== 
+# ==22396== Process terminating with default action of signal 11 (SIGSEGV): dumping core
+# ==22396==  Bad permissions for mapped region at address 0x483B000
+# ==22396==    at 0x4946397: select (in /usr/lib64/libc.so.6)
+# ==22396==    by 0x4020BA: run (select_var.h:26)
+# ==22396==    by 0x40B30C: fork_testrun (tst_test.c:1566)
+# ==22396==    by 0x40D4EF: tst_run_tcases (tst_test.c:1918)
+# ==22396==    by 0x401D4D: main (tst_test.h:725)
+
+skip = 0
+/==[0-9][0-9]*==/ { skip = 1 }
+/Process terminating with default action of signal 11/ { skip = 1; skipblock=1 }
+/by.*main.*tst_test.h/ { skip = 1; skipblock=0 }
+!skip && !skipblock { print }
diff --git a/auxprogs/ltp-excludes.txt b/auxprogs/ltp-excludes.txt
index 236d779426..275fd74854 100644
--- a/auxprogs/ltp-excludes.txt
+++ b/auxprogs/ltp-excludes.txt
@@ -1,5 +1,7 @@
+# Exclude the following syscall tests because they are too slow:
 bind06
 epoll-ltp
+fork13
 fork14
 futex_cmp_requeue01
 futex_cmp_requeue02
diff --git a/auxprogs/ltp-tester.sh b/auxprogs/ltp-tester.sh
index 54d807b0c2..ba8fd8be47 100755
--- a/auxprogs/ltp-tester.sh
+++ b/auxprogs/ltp-tester.sh
@@ -11,7 +11,9 @@ ORIG_PATH=$PATH
 SCRIPT_SRC=$(dirname $0)
 LOGDIR=${LOGDIR:-$LTP_SRC_DIR/ltp/tests}
 DIFFCMD="diff -u"
-VALGRIND="${VALGRIND:-$LTP_SRC_DIR/../../../vg-in-place}"
+# vgdb sensitive testcase: e.g. nftw01 nftw6401 setfsgid04 setfsgid03_16 symlink03
+VGARGS="-q --vgdb=no"
+VALGRIND="${VALGRIND:-$LTP_SRC_DIR/../../../vg-in-place} ${VGARGS}"
 # For parallel testing, consider IO intensive jobs, take nproc into account
 PARALLEL_JOBS=${PARALLEL_JOBS:-$(nproc)}
 # TESTS env var may be specified to restrict testing to selected test cases
@@ -37,24 +39,27 @@ doTest ()
     pushd $dir >/dev/null
         PATH="$ORIG_PATH:$PWD"
         ./$exe >$l/log1std 2>$l/log1err ||:
-        $VALGRIND -q --tool=none --log-file=$l/log2 ./$exe >$l/log2std 2>$l/log2err ||:
-        $VALGRIND -q --tool=memcheck --log-file=$l/log3 ./$exe >$l/log3std 2>$l/log3err ||:
-
-        # We want to make sure that LTP syscall tests give identical
-        # results with and without valgrind.  The test logs go to the
-        # stderr.  They aren't identical across individual runs. The
-        # differences include port numbers, temporary files, test
-        # output ordering changes and more. They aren't trivially
-        # comparable.  We resort to comparing at least the final
-        # summary of individual test results
-        tail -10 $l/log1err | grep -E "^(passed|failed|broken|skipped|warnings)" > $l/log1summary ||:
-        tail -10 $l/log2err | grep -E "^(passed|failed|broken|skipped|warnings)" > $l/log2summary ||:
-        tail -10 $l/log3err | grep -E "^(passed|failed|broken|skipped|warnings)" > $l/log3summary ||:
+        $VALGRIND --tool=none --log-file=$l/log2 ./$exe >$l/log2std 2>$l/log2err ||:
+        $VALGRIND --tool=memcheck --log-file=$l/log3 ./$exe >$l/log3std 2>$l/log3err ||:
+
+        for i in "$l"/log{1std,1err,2,2std,2err,3,3std,3err}; do
+            echo "# cat $(basename $i)" >> $LOGDIR/$exe.log
+            cat $i >> $LOGDIR/$exe.log
+        done
+
+        echo "# errors" >> $LOGDIR/$exe.log
+
+        # If there is a logfile filter, apply it
+        if test -f "${SCRIPT_SRC}/filters/${exe}"; then
+            cat $l/log2 | ${SCRIPT_SRC}/filters/${exe} > $l/log2.filtered
+        else
+            cat $l/log2 > $l/log2.filtered
+        fi
 
         # Check logs, report errors
         pushd $l >/dev/null
-            if test -s log2; then
-                echo -e "${exe}: unempty log2:\n$(cat log2)" | tee -a $LOGDIR/$exe.log
+            if test -s log2.filtered; then
+                echo -e "${exe}: unempty log2.filtered:\n$(cat log2.filtered)" | tee -a $LOGDIR/$exe.log
                 rv="FAIL"
             fi
 
@@ -63,17 +68,18 @@ doTest ()
                 rv="FAIL"
             fi
 
-            if ! ${DIFFCMD} log1summary log2summary >/dev/null; then
-                echo -e "${exe}: ${DIFFCMD} log1summary log2summary:\n$(${DIFFCMD} log1summary log2summary)" | tee -a $LOGDIR/$exe.log
+            if ! ${DIFFCMD} log1err log2err >/dev/null; then
+                echo -e "${exe}: ${DIFFCMD} log1err log2err:\n$(${DIFFCMD} log1err log2err)" | tee -a $LOGDIR/$exe.log
                 rv="FAIL"
             fi
 
-            if ! ${DIFFCMD} log2summary log3summary >/dev/null; then
-                echo -e "${exe}: ${DIFFCMD} log2summary log3summary:\n$(${DIFFCMD} log2summary log3summary)" | tee -a $LOGDIR/$exe.log
+            if ! ${DIFFCMD} log2err log3err >/dev/null; then
+                echo -e "${exe}: ${DIFFCMD} log2err log3err:\n$(${DIFFCMD} log2err log3err)" | tee -a $LOGDIR/$exe.log
                 rv="FAIL"
             fi
 
             # synthetize automake style testlogs for bunsen import
+            echo "# result" >> $LOGDIR/$exe.log
             echo ":test-result: $rv" | tee -a $LOGDIR/$exe.log > $LOGDIR/$exe.trs
         popd >/dev/null
     popd >/dev/null