valgrind-developers — Discussion list for developers of valgrind

Re: [Valgrind-developers] missing -Wformat warnings

[Sam J. <sa...@ge...>]

Paul Floyd via Valgrind-developers <val...@li...> writes:

> On 07/05/2025 18:55, Florian Krohm wrote:
>> Greetings.
>>
>> I noticed that the presence of -fno-builtin suppresses -Wformat warnings.
>> First I thought this to be a GCC bug but it is not.
>
> Strange. I don't see any relationship between the two.

The context is https://gcc.gnu.org/PR120148.

i.e. -fno-builtin means you don't get any format
attributes on the functions.

Re: [Valgrind-developers] missing -Wformat warnings

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

On 07/05/2025 18:55, Florian Krohm wrote:
> Greetings.
>
> I noticed that the presence of -fno-builtin suppresses -Wformat warnings.
> First I thought this to be a GCC bug but it is not.

Strange. I don't see any relationship between the two.

> -fno-builtin was added to Makefile.all.am in e8ce3f7abb mentioning 
> explicitly this to be needed for an LLVM workaround. The attached 
> patch moves this option to the COMPILER_IS_CLANG section and fixes the 
> fallout.
>
> AM_CFLAGS_PSO_BASE is not being changed because doing so causes
> memcheck/tests/wcpncpy and drd/tests/sem_open_traced to fail.
>
> Regtested on x86_64-linux-gnu and s390x-ibm-linux-gnu with no failures.
>
> OK ?

No. On openSUSE Leap 15.6 amd64 with GCC 14.2 I get link errors. We 
would need to provide a 'strlen' implementation at least for amd64 Linux.

Here are the errors:

../coregrind/link_tool_exe_linux 0x58000000 gcc-14     -o 
memcheck-amd64-linux  -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow 
-Wpointer-arith -Wstrict-prototypes -Wmissing-declarations 
-Wno-unused-result -Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body 
-Wformat -Wformat-signedness -Wformat-security -Wignored-qualifiers 
-Wmissing-parameter-type -Wlogical-op -Wenum-conversion 
-Wimplicit-fallthrough=2 -Wold-style-declaration -finline-functions 
-fno-stack-protector -fno-strict-aliasing   -fomit-frame-pointer -O2 
-static -nodefaultlibs -nostartfiles -u _start  -m64 
memcheck_amd64_linux-mc_leakcheck.o 
memcheck_amd64_linux-mc_malloc_wrappers.o memcheck_amd64_linux-mc_main.o 
memcheck_amd64_linux-mc_main_asm.o memcheck_amd64_linux-mc_translate.o 
memcheck_amd64_linux-mc_machine.o memcheck_amd64_linux-mc_errors.o 
../coregrind/libcoregrind-amd64-linux.a ../VEX/libvex-amd64-linux.a 
-lgcc ../coregrind/libgcc-sup-amd64-linux.a
/usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: 
../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-m_libcbase.o): 
in function `vgPlain_strlen':
/home/paulf/scratch/valgrind/coregrind/m_libcbase.c:263:(.text+0xc8e): 
undefined reference to `strlen'
/usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: 
/home/paulf/scratch/valgrind/coregrind/m_libcbase.c:263:(.text+0x106b): 
undefined reference to `strlen'
/usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: 
/home/paulf/scratch/valgrind/coregrind/m_libcbase.c:263:(.text+0x10db): 
undefined reference to `strlen'
/usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: 
/home/paulf/scratch/valgrind/coregrind/m_libcbase.c:263:(.text+0x1175): 
undefined reference to `strlen'
/usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: 
/home/paulf/scratch/valgrind/coregrind/m_libcbase.c:263:(.text+0x13fd): 
undefined reference to `strlen'
/usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: 
../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-m_libcbase.o):/home/paulf/scratch/valgrind/coregrind/m_libcbase.c:263: 
more undefined references to `strlen' follow

A+

Paul

[Valgrind-developers] missing -Wformat warnings

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

Greetings.

I noticed that the presence of -fno-builtin suppresses -Wformat warnings.
First I thought this to be a GCC bug but it is not.

-fno-builtin was added to Makefile.all.am in e8ce3f7abb mentioning explicitly 
this to be needed for an LLVM workaround. The attached patch moves this option 
to the COMPILER_IS_CLANG section and fixes the fallout.

AM_CFLAGS_PSO_BASE is not being changed because doing so causes
memcheck/tests/wcpncpy and drd/tests/sem_open_traced to fail.

Regtested on x86_64-linux-gnu and s390x-ibm-linux-gnu with no failures.

OK ?

   Florian

Re: [Valgrind-developers] ☠ Buildbot (Sourceware): valgrind - failed update (failure) (master)

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

Hi Florian,

On Wed, May 07, 2025 at 08:36:54AM +0200, Florian Krohm wrote:
> On 07.05.25 01:33, bu...@so... wrote:
> >A new failure has been detected on builder valgrind-fedora-x86_64 while building valgrind.
> >
> >Full details are available at:
> >     https://builder.sourceware.org/buildbot/#/builders/20/builds/1344
> >
> >Build state: failed update (failure)
> >Revision: (unknown)
> >Worker: bb1-1
> >Build Reason: (unknown)
> >Blamelist: Florian Krohm <fl...@ei...>
> >
> >Steps:
> >
> >- 0: worker_preparation ( success )
> >
> >- 1: git checkout ( failure )
> >     Logs:
> >         - stdio: https://builder.sourceware.org/buildbot/#/builders/20/builds/1344/steps/1/logs/stdio
> >
> 
> Looking at the URL above ..... Why do I get the blame?
> 
>  using PTY: False
> rm: cannot remove '/home/builder/shared/bb1-1/worker/valgrind-fedora-x86_64/build/valgrind-ltp-logs':
> Permission denied

Because the buildbot doesn't know the "real" blame should be on me
(sorry), who added the ltpchecks Step (wrongly). It simply warns any
patch Authors that it detected a problem. The Step has been corrected
now.

Cheers,

Mark

Re: [Valgrind-developers] ☠ Buildbot (Sourceware): valgrind - failed update (failure) (master)

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

On 07.05.25 01:33, bu...@so... wrote:
> A new failure has been detected on builder valgrind-fedora-x86_64 while building valgrind.
> 
> Full details are available at:
>      https://builder.sourceware.org/buildbot/#/builders/20/builds/1344
> 
> Build state: failed update (failure)
> Revision: (unknown)
> Worker: bb1-1
> Build Reason: (unknown)
> Blamelist: Florian Krohm <fl...@ei...>
> 
> Steps:
> 
> - 0: worker_preparation ( success )
> 
> - 1: git checkout ( failure )
>      Logs:
>          - stdio: https://builder.sourceware.org/buildbot/#/builders/20/builds/1344/steps/1/logs/stdio
> 

Looking at the URL above ..... Why do I get the blame?

  using PTY: False
rm: cannot remove 
'/home/builder/shared/bb1-1/worker/valgrind-fedora-x86_64/build/valgrind-ltp-logs': 
Permission denied
elapsedTime=0.000882
program finished with exit code 1

Re: [Valgrind-developers] Next version numbering

[Philippe W. <phi...@sk...>]

On Mon, 2025-05-05 at 13:22 +0000, LATHUILIERE Bruno wrote:
> Hi,
> 
> I think the tool verrou could be able to benefit from a multi-threaded version (at least for a subset of functionalities).
> I've well understood, a multi-threaded version is not for a near future. Nevertheless, do you have any advice for tool developers to be ready this revolution?   Typically, I'd like to know if it will be possible to use TLS?
No specific advice (yet at least) on how to develop tools.

A (the?) main problem to solve is to ensure that the tool code run by one thread has
little interactions (shared data structures) with other threads.
Memcheck V bit structure is quite desperate IMO.
For other tools (for example callgrind), to be looked at.

Thanks
Philippe

> 
> It sounds ridiculous "to do nothing faster", but for tools like callgrind or verrou which can select a part of the code to be instrumented it could be useful.
> 
> ++
> Bruno
> 
> 
> -----Message d'origine-----
> De : val...@li... <val...@li...>
> Envoyé : jeudi 1 mai 2025 09:58
> À : Paul Floyd <pj...@wa...>; val...@li...
> Objet : Re: [Valgrind-developers] Next version numbering
> 
> Expéditeur externe : Vérifier l'expéditeur avant de cliquer sur les liens ou pièces-jointes
> 
> External Sender : Check the sender before clicking any links or attachments
> 
> On Thu, 2025-05-01 at 09:40 +0200, Paul Floyd via Valgrind-developers wrote:
> > Hi all
> > 
> > I've been wondering whether we should switch to a year based numbering
> > scheme rather than our current semantic versioning. I'm not sure if
> > there will ever be a version 4. Making Valgrind multithreaded would
> > warrant such a change but I can't see that happening.
> 
> I did an experimental multithreaded trial some years ago, the prototype could run the none tool multi-threaded, so valgrind was able to do nothing faster :).
> But this stopped when I found no solution for memcheck.
> 
> I still believe a multi-threaded valgrind is relevant for some tools such as callgrind that do not depend (too much) on a "central data structure accessed on a permanent basis".
> 
> And maybe new things/instructions such as rseq might maybe provide a solution for memcheck (avoiding the performance killer to protect the memcheck V bits infrastructure for any access done by the guest).
> 
> But I agree with you that it is unlikely to appear very soon. On my side, I am not expecting to have time to work on that prototype before I am retired (but this time gets closer every day :).
> 
> > 
> > What I'm thinking of is 2025.04, 2025.10 etc.
> > 
> > Thoughts?
> 
> On this aspect, I do not have strong preference but the "year" based approach makes more clear when someone complains that they are using a (very) old release.
> 
> > 
> > A+
> > 
> > Paul
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Valgrind-developers mailing list
> > Val...@li...
> > https://list/
> > s.sourceforge.net%2Flists%2Flistinfo%2Fvalgrind-developers&data=05%7C0
> > 2%7Cbruno.lathuiliere%40edf.fr%7Cb1235c6617ec44ac5b9f08dd88883a49%7Ce2
> > 42425b70fc44dc9ddfc21e304e6c80%7C1%7C0%7C638816840845605483%7CUnknown%
> > 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
> > MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=B%2ByBnnYvvJ60
> > %2F9zAq1%2F56V21COCltsHFR5lW2rIXScA%3D&reserved=0
> 
> 
> 
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
> 
> Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.
> 
> Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.
> 
> Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.
> ____________________________________________________
> 
> This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.
> 
> If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.
> 
> E-mail communication cannot be guaranteed to be timely secure, error or virus-free.
> 

[Valgrind-developers] [valgrind] s390x: BPRP related fixes

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

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

commit cb266a0b87b3e6d432b8f1d4d0cbe0351222d783
Author: Florian Krohm <fl...@ei...>
Date:   Tue May 6 21:22:47 2025 +0000

    s390x: BPRP related fixes
    
    objdump disassembly for BPRP looks like so:
    
    c5 0f ff 00 00 00   bprp  0,88 <main+0x88>,8a <main+0x8a>
    
    But the disasm-test parser assumed there could only be one
    address including a symbol name on a given line. It stopped
    comparison beyond that point.
    The line
    
    c5 0f ff 00 00 00   bprp  0,88 <main+0x88>,fffe <main+0xfffe>
    
    would compare equal to the above -- a false positive.
    
    Once fixed, BPRP testcases began failing. This is because the i3
    field is 24 bit wide. So an UShort is not good enough to represent
    it.

Diff:
---
 VEX/priv/guest_s390_toIR.c             |  8 ++---
 none/tests/s390x/disasm-test/objdump.c | 11 ------
 none/tests/s390x/disasm-test/verify.c  | 64 ++++++++++++++++++++++++++--------
 3 files changed, 54 insertions(+), 29 deletions(-)

diff --git a/VEX/priv/guest_s390_toIR.c b/VEX/priv/guest_s390_toIR.c
index 405bcfa7f0..b3ee122c5a 100644
--- a/VEX/priv/guest_s390_toIR.c
+++ b/VEX/priv/guest_s390_toIR.c
@@ -2757,8 +2757,8 @@ s390_format_E(const HChar *(*irgen)(void))
 }
 
 static void
-s390_format_MII_UPP(const HChar *(*irgen)(UChar m1, UShort i2, UShort i3),
-                    UChar m1, UShort i2, UShort i3)
+s390_format_MII_UPP(const HChar *(*irgen)(UChar m1, UShort i2, UInt i3),
+                    UChar m1, UShort i2, UInt i3)
 {
    const HChar *mnm;
 
@@ -2766,7 +2766,7 @@ s390_format_MII_UPP(const HChar *(*irgen)(UChar m1, UShort i2, UShort i3),
 
    if (UNLIKELY(vex_traceflags & VEX_TRACE_FE))
       S390_DISASM(MNM(mnm), UINT(m1), PCREL((Int)((Short)(i2 << 4) >> 4)),
-                  PCREL((Int)(Short)i3));
+                  PCREL((Int)(i3 << 8) >> 8));
 }
 
 static void
@@ -20621,7 +20621,7 @@ s390_irgen_BPP(UChar m1, UShort i2, IRTemp op3addr)
 }
 
 static const HChar *
-s390_irgen_BPRP(UChar m1, UShort i2, UShort i3)
+s390_irgen_BPRP(UChar m1, UShort i2, UInt i3)
 {
    /* Treat as a no-op */
    return "bprp";
diff --git a/none/tests/s390x/disasm-test/objdump.c b/none/tests/s390x/disasm-test/objdump.c
index 7100e47420..1646fe9baf 100644
--- a/none/tests/s390x/disasm-test/objdump.c
+++ b/none/tests/s390x/disasm-test/objdump.c
@@ -153,17 +153,6 @@ read_objdump(const char *file)
 
       char *dis_insn = p;
 
-      /* Remove symbolic jump targets, if any. E.g. change
-         1b68:    c0 e5 ff ff fd a4    brasl   %r14,16b0 <puts@plt>  to
-         1b68:    c0 e5 ff ff fd a4    brasl   %r14,16b0
-      */
-      p = strchr(p, '<');
-      if (p) {
-         *p-- = '\0';
-         while (isspace(*p))   // remove trailing white space
-            *p-- = '\0';
-      }
-
       if (strncmp(dis_insn, mark, strlen(mark)) == 0) {
          if (marker_seen)
             break;          // we're done
diff --git a/none/tests/s390x/disasm-test/verify.c b/none/tests/s390x/disasm-test/verify.c
index 2d6fe48c05..8dee9f596a 100644
--- a/none/tests/s390x/disasm-test/verify.c
+++ b/none/tests/s390x/disasm-test/verify.c
@@ -121,27 +121,63 @@ disasm_same(const char *from_objdump, const char *from_vex,
    const char *p2 = from_vex;
 
    while (42) {
+      while (isspace(*p1))
+         ++p1;
+      while (isspace(*p2))
+         ++p2;
       if (*p1 == '\0' && *p2 == '\0')
          return 1;
       if (*p1 == '\0' || *p2 == '\0')
          return 0;
+
+      if (*p1 == *p2) {
+         ++p1;
+         ++p2;
+         continue;
+      }
+
+      /* Consider the case where the VEX disassembly has ".+integer"
+         or ".-integer" and the objdump disassembly has an hex address
+         possibly followed by a symbolic address, e.g. <main+0xe>. */
+      if (*p2++ != '.') return 0;
+
+      long long offset_in_bytes = 0;
+      unsigned long long target_address = 0;
+
+      while (isxdigit(*p1)) {
+         target_address *= 16;
+         if (isdigit(*p1))
+            target_address += *p1 - '0';
+         else {
+            int c = tolower(*p1);
+            if (c >= 'a' && c <= 'f')
+               target_address += 10 + c - 'a';
+            else
+               return 0;  // error
+         }
+         ++p1;
+      }
       while (isspace(*p1))
          ++p1;
-      while (isspace(*p2))
+      if (*p1 == '<') {
+         while (*p1++ != '>')
+            ;
+      }
+
+      int is_negative = 0;
+      if (*p2 == '-') {
+         is_negative = 1;
+         ++p2;
+      } else if (*p2 == '+')
+         ++p2;
+      while (isdigit(*p2)) {
+         offset_in_bytes *= 10;
+         offset_in_bytes += *p2 - '0';
          ++p2;
-      if (*p1 != *p2) {
-         long long offset_in_bytes;
-         unsigned long long target_address;
-
-         /* Consider the case where the VEX disassembly has ".+integer"
-            or ".-integer" and the objdump disassembly has an
-            address. */
-         if (*p2++ != '.') return 0;
-         if (sscanf(p2, "%lld", &offset_in_bytes) != 1) return 0;
-         if (sscanf(p1, "%llx", &target_address)  != 1) return 0;
-         return address + offset_in_bytes == target_address;
       }
-      ++p1;
-      ++p2;
+      if (is_negative)
+         offset_in_bytes *= -1;
+
+      if (address + offset_in_bytes != target_address) return 0;
    }
 }

[Valgrind-developers] [valgrind] Run the LTP syscall tests in parallel

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

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

commit 0ce068434ec359324ff1e27f0c7bd5df8ae4e813
Author: Martin Cermak <mc...@re...>
Date:   Mon May 5 14:23:16 2025 +0200

    Run the LTP syscall tests in parallel
    
    - Run the LTP syscall tests in parallel to save time.
    - Allow for running only selected tests using TESTS env var.

Diff:
---
 auxprogs/Makefile.am   |  6 ++++++
 auxprogs/ltp-tester.sh | 58 +++++++++++++++++++++++++++++++++++++-------------
 2 files changed, 49 insertions(+), 15 deletions(-)

diff --git a/auxprogs/Makefile.am b/auxprogs/Makefile.am
index 9cec4f222b..3a2d0d1762 100644
--- a/auxprogs/Makefile.am
+++ b/auxprogs/Makefile.am
@@ -231,7 +231,13 @@ gsl-check: $(GSL_BUILD_DIR)/gsl-build
 	diff -u $(abs_top_srcdir)/auxprogs/gsl-1.6.out.x86.exp \
 		$(GSL_BUILD_DIR)/valgrind-gsl.out
 
+# Extract -jNUM from MAKEFLAGS.
+# Note that any spaces between -j and NUM have already been removed.
+# Also there will be only one (the last) -jNUM left in MAKEFLAGS.
+PARALLEL_JOBS=$(subst -j,,$(filter -j%,$(MAKEFLAGS)))
+
 ltp-check: $(LTP_SRC_DIR)
+	PARALLEL_JOBS=$(PARALLEL_JOBS) \
 	LTP_SRC_DIR=$(LTP_SRC_DIR) \
 	VALGRIND=$(abs_top_builddir)/vg-in-place \
 	  $(abs_top_srcdir)/auxprogs/ltp-tester.sh
diff --git a/auxprogs/ltp-tester.sh b/auxprogs/ltp-tester.sh
index 000cfaa7f3..e31f8a6b12 100755
--- a/auxprogs/ltp-tester.sh
+++ b/auxprogs/ltp-tester.sh
@@ -13,31 +13,30 @@ LOGDIR=${LOGDIR:-$LTP_SRC_DIR/valgrind-ltp-logs}
 SUMMARY_LOG="$LOGDIR/summary.log"
 DIFFCMD="diff -u"
 VALGRIND="${VALGRIND:-$LTP_SRC_DIR/../../../vg-in-place}"
+# 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
 
 # Initialize LOGDIR
-mkdir -p $LOGDIR; rm -rf $LOGDIR/*
+mkdir -p $LOGDIR; rm -rf ${LOGDIR:?}/*
 
 myLog ()
 {
     msg="$1"
     echo "$msg"
-    echo -e "FAIL: $msg" >> $SUMMARY_LOG
+    echo -e "FAIL: $msg" >> summary
 }
 
-cd $LTP_SRC_DIR
-
-mapfile -t files < <(find testcases/kernel/syscalls -executable -and -type f \
-                     | sort | grep -v -f $ORIG_PWD/ltp-excludes.txt)
-c=${#files[@]}; i=0
-
-for test in "${files[@]}"; do
-    dir=$(dirname $test)
-    exe=$(basename $test)
+doTest ()
+{
+    t=$1
+    nr=$2
+    dir=$(dirname $t)
+    exe=$(basename $t)
     l="$LOGDIR/$exe"
     mkdir -p $l
-    i=$((++i))
+    echo "[$nr/$c] Testing $exe ..." | tee -a $l/summary
     pushd $dir >/dev/null
-        echo "[$i/$c] Testing $exe ..." | tee -a $SUMMARY_LOG
         PATH="$ORIG_PATH:$PWD"
         ./$exe >$l/log1std 2>$l/log1err ||:
         $VALGRIND -q --tool=none --log-file=$l/log2 ./$exe >$l/log2std 2>$l/log2err ||:
@@ -60,7 +59,7 @@ for test in "${files[@]}"; do
                 myLog "${exe}: unempty log2:\n$(cat log2)"
             fi
 
-            if grep -f $ORIG_PWD/ltp-error-patterns.txt * > error-patterns-found.txt; then
+            if grep -f $ORIG_PWD/ltp-error-patterns.txt log* > error-patterns-found.txt; then
                 myLog "${exe}: error string found:\n$(cat error-patterns-found.txt)"
             fi
 
@@ -73,7 +72,36 @@ for test in "${files[@]}"; do
             fi
         popd >/dev/null
     popd >/dev/null
+}
+
+cd $LTP_SRC_DIR
+
+if [ -n "$TESTS" ]; then
+    echo "Running individual syscall tests specified in the TESTS env var ..."
+    mapfile -t files < <(find testcases/kernel/syscalls -executable -and -type f \
+                         | sort | grep -f <(echo $TESTS | tr ' ' '\n' | sed 's/.*/\/\0$/'))
+else
+    echo "Running whole the LTP syscall testsuite ..."
+    mapfile -t files < <(find testcases/kernel/syscalls -executable -and -type f \
+                         | sort | grep -v -f $ORIG_PWD/ltp-excludes.txt)
+fi
+
+c=${#files[@]}; i=0
+
+# Run tests in parallel
+for test in "${files[@]}"; do
+    while test "$(jobs -l | wc -l)" -gt $PARALLEL_JOBS; do sleep 0.1; done
+    i=$((++i))
+    doTest $test $i &
 done
 
-echo "TESTING FINISHED, logs in $LOGDIR"
+wait
 
+# Reconstruct $SUMMARY_LOG
+for test in "${files[@]}"; do
+    exe=$(basename $test)
+    l="$LOGDIR/$exe"
+    cat $l/summary >> $SUMMARY_LOG
+done
+
+echo "TESTING FINISHED, logs in $LOGDIR"

[Valgrind-developers] [valgrind] s390x: disasm-test: Fix compiler warning (BZ 503817)

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

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

commit 685affd00645ea5d4492897d372e457bfc8cf838
Author: Florian Krohm <fl...@ei...>
Date:   Tue May 6 08:53:04 2025 +0000

    s390x: disasm-test: Fix compiler warning (BZ 503817)
    
    Forgotten pointer dereference. Beef up unit test accordingly.
    Fix a few -Wsign-compare compiler warnings along the way.
    
    Fixes https://bugs.kde.org/show_bug.cgi?id=503817

Diff:
---
 NEWS                                  |  1 +
 none/tests/s390x/disasm-test/opcode.c | 16 ++++++++--------
 2 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/NEWS b/NEWS
index b69dc84f8b..7c66ec08bb 100644
--- a/NEWS
+++ b/NEWS
@@ -25,6 +25,7 @@ are not entered into bugzilla tend to get forgotten about or ignored.
 
 503641  close_range syscalls started failing with 3.25.0
 503677  duplicated-cond compiler warning in dis_RV64M
+503817  s390x: fix 'ordered comparison of pointer with integer zero' compiler warnings
 
 To see details of a given bug, visit
   https://bugs.kde.org/show_bug.cgi?id=XXXXXX
diff --git a/none/tests/s390x/disasm-test/opcode.c b/none/tests/s390x/disasm-test/opcode.c
index e638c973c5..6acf25ec7b 100644
--- a/none/tests/s390x/disasm-test/opcode.c
+++ b/none/tests/s390x/disasm-test/opcode.c
@@ -1408,11 +1408,11 @@ parse_int(const char *p, int is_unsigned, long long *val)
       error("integer expected\n");
       return p;
    }
-   if (is_unsigned && val < 0) {
+   if (is_unsigned && *val < 0) {
       error("unsigned value expected\n");
       return p;
    }
-   return skip_digits(val < 0 ? p + 1 : p);
+   return skip_digits(*val < 0 ? p + 1 : p);
 }
 
 
@@ -1834,7 +1834,7 @@ get_opcode_by_name(const char *name)
 {
    unsigned len = strlen(name);
 
-   for (int i = 0; i < num_opcodes; ++i) {
+   for (unsigned i = 0; i < num_opcodes; ++i) {
       const char *op = opcodes[i];
       if (strncmp(op, name, len) == 0 &&
           (op[len] == ' ' || op[len] == '\0'))
@@ -1966,7 +1966,7 @@ parse_opcode(const char *spec)
 
    if (debug) {
       printf("opcode: |%s|\n", opc->name);
-      for (int i = 0; i < opc->num_opnds; ++i) {
+      for (unsigned i = 0; i < opc->num_opnds; ++i) {
          const opnd *d = opc->opnds + i;
          printf("opnd %2d: %-8s  type: %-5s", i, d->name,
                 opnd_kind_as_string(d->kind));
@@ -1977,7 +1977,7 @@ parse_opcode(const char *spec)
          if (d->allowed_values) {
             printf("  values:");
             unsigned nval = d->allowed_values[0];
-            for (int j = 1; j <= nval; ++j) {
+            for (unsigned j = 1; j <= nval; ++j) {
                if (d->is_unsigned)
                   printf(" %u", (unsigned)d->allowed_values[j]);
                else
@@ -2005,7 +2005,7 @@ get_opcode_by_index(unsigned ix)
 void
 release_opcode(opcode *opc)
 {
-   for (int i = 0; i < opc->num_opnds; ++i) {
+   for (unsigned i = 0; i < opc->num_opnds; ++i) {
       const opnd *q = opc->opnds + i;
       free(q->name);
       free(q->allowed_values);
@@ -2026,7 +2026,7 @@ static const char *unit_tests[] = {
    "err1 m", "err2 m2:", "err3 m3:s", "err4 m4:s5",
    "err5 m5{", "err6 m6:{", "err7 m7:{}", "err8 m8:{1", "err9 m9:{1,",
    "err10 m0:{2..}", "err11 m11:{2..1}", "err12 m11:u{1,2}",
-   "err13 m13:r", "err14 m14:u"
+   "err13 m13:r", "err14 m14:u", "err15 q1:u5{-1},q2:u8{3..1}"
 };
 
 
@@ -2037,6 +2037,6 @@ run_unit_tests(void)
 
    debug = 1;
 
-   for (int i = 0; i < num_tests; ++i)
+   for (unsigned i = 0; i < num_tests; ++i)
       parse_opcode(unit_tests[i]);
 }

Re: [Valgrind-developers] valgrind riscv-linux port integrated

[Jojo R <rj...@gm...>]

在 2025/3/4 04:49, Petr Pavlu 写道:
> On 2/25/25 11:27 PM, Mark Wielaard wrote:
>> Hi all,
>>
>> The riscv-linux port started by Petr Pavlu and discussed in
>> https://bugs.kde.org/show_bug.cgi?id=468575
>> has finally been integrated into the main valgrind sources.
> Great to hear that. Thank you!

It's big news, thanks for your efforts :)


>> We don't have a valgrind riscv arch maintainer yet (any volunteers?)
> I plan to continue contributing to the port. I've been quite busy lately
> but I hope things could improve in a few months. If anyone else is
> willing to help with the maintainership, it would be welcome.

We could help to maintain the riscv arch also, i hope more developers to 
join RISCV :)

This port is the first step for RISCV in valgrind, it's very helpful for 
following complicated patch like:

https://bugs.kde.org/show_bug.cgi?id=468979


> Cheers,
> Petr

Cheers,
Jojo

Re: [Valgrind-developers] Next version numbering

[LATHUILIERE B. <bru...@ed...>]

Hi,

I think the tool verrou could be able to benefit from a multi-threaded version (at least for a subset of functionalities).
I've well understood, a multi-threaded version is not for a near future. Nevertheless, do you have any advice for tool developers to be ready this revolution?   Typically, I'd like to know if it will be possible to use TLS?

It sounds ridiculous "to do nothing faster", but for tools like callgrind or verrou which can select a part of the code to be instrumented it could be useful.

++
Bruno


-----Message d'origine-----
De : val...@li... <val...@li...>
Envoyé : jeudi 1 mai 2025 09:58
À : Paul Floyd <pj...@wa...>; val...@li...
Objet : Re: [Valgrind-developers] Next version numbering

Expéditeur externe : Vérifier l'expéditeur avant de cliquer sur les liens ou pièces-jointes

External Sender : Check the sender before clicking any links or attachments

On Thu, 2025-05-01 at 09:40 +0200, Paul Floyd via Valgrind-developers wrote:
> Hi all
>
> I've been wondering whether we should switch to a year based numbering
> scheme rather than our current semantic versioning. I'm not sure if
> there will ever be a version 4. Making Valgrind multithreaded would
> warrant such a change but I can't see that happening.

I did an experimental multithreaded trial some years ago, the prototype could run the none tool multi-threaded, so valgrind was able to do nothing faster :).
But this stopped when I found no solution for memcheck.

I still believe a multi-threaded valgrind is relevant for some tools such as callgrind that do not depend (too much) on a "central data structure accessed on a permanent basis".

And maybe new things/instructions such as rseq might maybe provide a solution for memcheck (avoiding the performance killer to protect the memcheck V bits infrastructure for any access done by the guest).

But I agree with you that it is unlikely to appear very soon. On my side, I am not expecting to have time to work on that prototype before I am retired (but this time gets closer every day :).

>
> What I'm thinking of is 2025.04, 2025.10 etc.
>
> Thoughts?

On this aspect, I do not have strong preference but the "year" based approach makes more clear when someone complains that they are using a (very) old release.

>
> A+
>
> Paul
>
>
>
>
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://list/
> s.sourceforge.net%2Flists%2Flistinfo%2Fvalgrind-developers&data=05%7C0
> 2%7Cbruno.lathuiliere%40edf.fr%7Cb1235c6617ec44ac5b9f08dd88883a49%7Ce2
> 42425b70fc44dc9ddfc21e304e6c80%7C1%7C0%7C638816840845605483%7CUnknown%
> 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=B%2ByBnnYvvJ60
> %2F9zAq1%2F56V21COCltsHFR5lW2rIXScA%3D&reserved=0



_______________________________________________
Valgrind-developers mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-developers

Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.

Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.

Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.
____________________________________________________

This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.

If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.

E-mail communication cannot be guaranteed to be timely secure, error or virus-free.

[Valgrind-developers] [valgrind] s390x: Follow-up to 558f5e9517

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

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

commit 64beb80f9757566049fa6064048b700210836b51
Author: Florian Krohm <fl...@ei...>
Date:   Sun May 4 22:30:25 2025 +0000

    s390x: Follow-up to 558f5e9517
    
    Said patch removes the resteering machinery which allowed chasing through
    unconditional jumps/calls during IR generation.
    There were two fixme's related to this which are now removed.
    Also eliminate functions 'call_function_and_chase' and
    'always_goto_and_chase' which no longer are meaningful. Use
    'call_function' and 'always_goto' instead.

Diff:
---
 VEX/priv/guest_s390_toIR.c | 48 ++++++++++++----------------------------------
 1 file changed, 12 insertions(+), 36 deletions(-)

diff --git a/VEX/priv/guest_s390_toIR.c b/VEX/priv/guest_s390_toIR.c
index a28043a62e..405bcfa7f0 100644
--- a/VEX/priv/guest_s390_toIR.c
+++ b/VEX/priv/guest_s390_toIR.c
@@ -507,16 +507,6 @@ call_function(IRExpr *callee_address)
    dis_res->jk_StopHere = Ijk_Call;
 }
 
-/* Function call with known target. */
-static void
-call_function_and_chase(Addr64 callee_address)
-{
-   put_IA(mkaddr_expr(callee_address));
-
-   dis_res->whatNext = Dis_StopHere;
-   dis_res->jk_StopHere = Ijk_Call;
-}
-
 /* Function return sequence */
 static void
 return_from_function(IRExpr *return_address)
@@ -578,18 +568,6 @@ always_goto(IRExpr *target)
    dis_res->jk_StopHere = Ijk_Boring;
 }
 
-
-/* An unconditional branch to a known target. */
-// QQQQ fixme this is now the same as always_goto
-static void
-always_goto_and_chase(Addr64 target)
-{
-   put_IA(mkaddr_expr(target));
-
-   dis_res->whatNext    = Dis_StopHere;
-   dis_res->jk_StopHere = Ijk_Boring;
-}
-
 /* A system call */
 static void
 system_call(IRExpr *sysno)
@@ -5799,7 +5777,7 @@ static const HChar *
 s390_irgen_BRAS(UChar r1, UShort i2)
 {
    put_gpr_dw0(r1, mkU64(guest_IA_next_instr));
-   call_function_and_chase(addr_relative(i2));
+   call_function(mkaddr_expr(addr_relative(i2)));
 
    return "bras";
 }
@@ -5808,7 +5786,7 @@ static const HChar *
 s390_irgen_BRASL(UChar r1, UInt i2)
 {
    put_gpr_dw0(r1, mkU64(guest_IA_next_instr));
-   call_function_and_chase(addr_rel_long(i2));
+   call_function(mkaddr_expr(addr_rel_long(i2)));
 
    return "brasl";
 }
@@ -5821,7 +5799,7 @@ s390_irgen_BRC(UChar m1, UShort i2)
    if (m1 == 0) {
    } else {
       if (m1 == 15) {
-         always_goto_and_chase(addr_relative(i2));
+         always_goto(mkaddr_expr(addr_relative(i2)));
       } else {
          assign(cond, s390_call_calculate_cond(m1));
          if_condition_goto(binop(Iop_CmpNE32, mkexpr(cond), mkU32(0)),
@@ -5843,7 +5821,7 @@ s390_irgen_BRCL(UChar m1, UInt i2)
    if (m1 == 0) {
    } else {
       if (m1 == 15) {
-         always_goto_and_chase(addr_rel_long(i2));
+         always_goto(mkaddr_expr(addr_rel_long(i2)));
       } else {
          assign(cond, s390_call_calculate_cond(m1));
          if_condition_goto(binop(Iop_CmpNE32, mkexpr(cond), mkU32(0)),
@@ -6154,7 +6132,7 @@ s390_irgen_CRJ(UChar r1, UChar r2, UShort i4, UChar m3)
    if (m3 == 0) {
    } else {
       if (m3 == 14) {
-         always_goto_and_chase(addr_relative(i4));
+         always_goto(mkaddr_expr(addr_relative(i4)));
       } else {
          assign(op1, get_gpr_w1(r1));
          assign(op2, get_gpr_w1(r2));
@@ -6179,7 +6157,7 @@ s390_irgen_CGRJ(UChar r1, UChar r2, UShort i4, UChar m3)
    if (m3 == 0) {
    } else {
       if (m3 == 14) {
-         always_goto_and_chase(addr_relative(i4));
+         always_goto(mkaddr_expr(addr_relative(i4)));
       } else {
          assign(op1, get_gpr_dw0(r1));
          assign(op2, get_gpr_dw0(r2));
@@ -6252,7 +6230,7 @@ s390_irgen_CIJ(UChar r1, UChar m3, UShort i4, UChar i2)
    if (m3 == 0) {
    } else {
       if (m3 == 14) {
-         always_goto_and_chase(addr_relative(i4));
+         always_goto(mkaddr_expr(addr_relative(i4)));
       } else {
          assign(op1, get_gpr_w1(r1));
          op2 = (Int)(Char)i2;
@@ -6277,7 +6255,7 @@ s390_irgen_CGIJ(UChar r1, UChar m3, UShort i4, UChar i2)
    if (m3 == 0) {
    } else {
       if (m3 == 14) {
-         always_goto_and_chase(addr_relative(i4));
+         always_goto(mkaddr_expr(addr_relative(i4)));
       } else {
          assign(op1, get_gpr_dw0(r1));
          op2 = (Long)(Char)i2;
@@ -7000,7 +6978,7 @@ s390_irgen_CLRJ(UChar r1, UChar r2, UShort i4, UChar m3)
    if (m3 == 0) {
    } else {
       if (m3 == 14) {
-         always_goto_and_chase(addr_relative(i4));
+         always_goto(mkaddr_expr(addr_relative(i4)));
       } else {
          assign(op1, get_gpr_w1(r1));
          assign(op2, get_gpr_w1(r2));
@@ -7025,7 +7003,7 @@ s390_irgen_CLGRJ(UChar r1, UChar r2, UShort i4, UChar m3)
    if (m3 == 0) {
    } else {
       if (m3 == 14) {
-         always_goto_and_chase(addr_relative(i4));
+         always_goto(mkaddr_expr(addr_relative(i4)));
       } else {
          assign(op1, get_gpr_dw0(r1));
          assign(op2, get_gpr_dw0(r2));
@@ -7098,7 +7076,7 @@ s390_irgen_CLIJ(UChar r1, UChar m3, UShort i4, UChar i2)
    if (m3 == 0) {
    } else {
       if (m3 == 14) {
-         always_goto_and_chase(addr_relative(i4));
+         always_goto(mkaddr_expr(addr_relative(i4)));
       } else {
          assign(op1, get_gpr_w1(r1));
          op2 = (UInt)i2;
@@ -7123,7 +7101,7 @@ s390_irgen_CLGIJ(UChar r1, UChar m3, UShort i4, UChar i2)
    if (m3 == 0) {
    } else {
       if (m3 == 14) {
-         always_goto_and_chase(addr_relative(i4));
+         always_goto(mkaddr_expr(addr_relative(i4)));
       } else {
          assign(op1, get_gpr_dw0(r1));
          op2 = (ULong)i2;
@@ -23946,8 +23924,6 @@ disInstr_S390_WRK(const UChar *insn)
    dres.jk_StopHere = Ijk_INVALID;
    dres.hint        = Dis_HintNone;
 
-   /* fixs390: consider chasing of conditional jumps */
-
    /* Normal and special instruction handling starts here. */
    if (s390_decode_and_irgen(insn, insn_length, &dres) == 0) {
       /* All decode failures end up here. The decoder has already issued an

[Valgrind-developers] [valgrind] s390x: Add disassembly for special insns

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

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

commit 0a4aef0523aae920fd3f102e1e4b2f4aaf501d05
Author: Florian Krohm <fl...@ei...>
Date:   Sun May 4 21:29:34 2025 +0000

    s390x: Add disassembly for special insns
    
    Surely we want to see this when tracing the frintend.
    Also: new function s390_irgen_inject_ir to wrap the handling of
    the special insn for IR injection.

Diff:
---
 VEX/priv/guest_s390_toIR.c | 52 ++++++++++++++++++++++++++++------------------
 1 file changed, 32 insertions(+), 20 deletions(-)

diff --git a/VEX/priv/guest_s390_toIR.c b/VEX/priv/guest_s390_toIR.c
index 102c6a9034..a28043a62e 100644
--- a/VEX/priv/guest_s390_toIR.c
+++ b/VEX/priv/guest_s390_toIR.c
@@ -20676,8 +20676,8 @@ s390_irgen_PPA(UChar m3, UChar r1, UChar r2)
 static void
 s390_irgen_client_request(void)
 {
-   if (0)
-      vex_printf("%%R3 = client_request ( %%R2 )\n");
+   if (UNLIKELY(vex_traceflags & VEX_TRACE_FE))
+      vex_printf("special insn: client_request");
 
    Addr64 next = guest_IA_curr_instr + S390_SPECIAL_OP_PREAMBLE_SIZE
                                      + S390_SPECIAL_OP_SIZE;
@@ -20691,8 +20691,8 @@ s390_irgen_client_request(void)
 static void
 s390_irgen_guest_NRADDR(void)
 {
-   if (0)
-      vex_printf("%%R3 = guest_NRADDR\n");
+   if (UNLIKELY(vex_traceflags & VEX_TRACE_FE))
+      vex_printf("special insn: guest_NRADDR");
 
    put_gpr_dw0(3, IRExpr_Get(S390X_GUEST_OFFSET(guest_NRADDR), Ity_I64));
 }
@@ -20700,6 +20700,9 @@ s390_irgen_guest_NRADDR(void)
 static void
 s390_irgen_call_noredir(void)
 {
+   if (UNLIKELY(vex_traceflags & VEX_TRACE_FE))
+      vex_printf("special insn: call_noredir");
+
    Addr64 next = guest_IA_curr_instr + S390_SPECIAL_OP_PREAMBLE_SIZE
                                      + S390_SPECIAL_OP_SIZE;
 
@@ -20713,6 +20716,30 @@ s390_irgen_call_noredir(void)
    dis_res->jk_StopHere = Ijk_NoRedir;
 }
 
+static void
+s390_irgen_inject_ir(void)
+{
+   if (UNLIKELY(vex_traceflags & VEX_TRACE_FE))
+      vex_printf("special insn: inject_ir");
+
+   vex_inject_ir(irsb, Iend_BE);
+
+   /* Invalidate the current insn. The reason is that the IRop we're
+      injecting here can change. In which case the translation has to
+      be redone. For ease of handling, we simply invalidate all the
+      time. */
+   stmt(IRStmt_Put(S390X_GUEST_OFFSET(guest_CMSTART),
+                   mkU64(guest_IA_curr_instr)));
+   stmt(IRStmt_Put(S390X_GUEST_OFFSET(guest_CMLEN),
+                   mkU64(guest_IA_next_instr - guest_IA_curr_instr)));
+   vassert(guest_IA_next_instr - guest_IA_curr_instr ==
+           S390_SPECIAL_OP_PREAMBLE_SIZE + S390_SPECIAL_OP_SIZE);
+
+   put_IA(mkaddr_expr(guest_IA_next_instr));
+   dis_res->whatNext    = Dis_StopHere;
+   dis_res->jk_StopHere = Ijk_InvalICache;
+}
+
 static s390_decode_t
 s390_decode_2byte_and_irgen(const UChar *bytes)
 {
@@ -23775,22 +23802,7 @@ s390_decode_special_and_irgen(const UChar *bytes)
    } else if (bytes[0] == 0x18 && bytes[1] == 0x44 /* lr %r4, %r4 */) {
       s390_irgen_call_noredir();
    } else if (bytes[0] == 0x18 && bytes[1] == 0x55 /* lr %r5, %r5 */) {
-      vex_inject_ir(irsb, Iend_BE);
-
-      /* Invalidate the current insn. The reason is that the IRop we're
-         injecting here can change. In which case the translation has to
-         be redone. For ease of handling, we simply invalidate all the
-         time. */
-      stmt(IRStmt_Put(S390X_GUEST_OFFSET(guest_CMSTART),
-                      mkU64(guest_IA_curr_instr)));
-      stmt(IRStmt_Put(S390X_GUEST_OFFSET(guest_CMLEN),
-                      mkU64(guest_IA_next_instr - guest_IA_curr_instr)));
-      vassert(guest_IA_next_instr - guest_IA_curr_instr ==
-              S390_SPECIAL_OP_PREAMBLE_SIZE + S390_SPECIAL_OP_SIZE);
-
-      put_IA(mkaddr_expr(guest_IA_next_instr));
-      dis_res->whatNext    = Dis_StopHere;
-      dis_res->jk_StopHere = Ijk_InvalICache;
+      s390_irgen_inject_ir();
    } else {
       /* We don't know what it is. */
       return S390_DECODE_UNKNOWN_SPECIAL_INSN;

[Valgrind-developers] [valgrind] ltp-excludes: Add fork14, futex_cmp_requeue and pidfd_send_signal

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

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

commit ecff86148825f0c6e58e55029b1d842839559ab0
Author: Mark Wielaard <ma...@kl...>
Date:   Sun May 4 20:16:26 2025 +0200

    ltp-excludes: Add fork14, futex_cmp_requeue and pidfd_send_signal
    
    There are a few more linux test project syscall tests that seem to
    cause some trouble for some buildbots. The fork14 test uses a lot of
    memory, as do the futex_cmp_requeue tests (at least on ppc64le). And
    the pidfd_send_signal tests, when run inside a container, seem to kill
    the test wrapper (and the container it runs in).

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

diff --git a/auxprogs/ltp-excludes.txt b/auxprogs/ltp-excludes.txt
index 5b1d898c80..236d779426 100644
--- a/auxprogs/ltp-excludes.txt
+++ b/auxprogs/ltp-excludes.txt
@@ -1,7 +1,13 @@
 bind06
 epoll-ltp
+fork14
+futex_cmp_requeue01
+futex_cmp_requeue02
 inotify09
 msgstress01
+pidfd_send_signal01
+pidfd_send_signal02
+pidfd_send_signal03
 sendmsg03
 setsockopt06
 setsockopt07

[Valgrind-developers] [COMMITTED] valgrind_ltpchecks_step: Simplify log file copying

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

log files were copied individually all into one directory which caused
overlapping log file names. Just move the whole log file and log dir.
---
 builder/master.cfg | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/builder/master.cfg b/builder/master.cfg
index 26d13fa60b1b..bbf35cce3d1f 100644
--- a/builder/master.cfg
+++ b/builder/master.cfg
@@ -4951,9 +4951,7 @@ valgrind_regtest_step = steps.Test(
 # And we just copy the logs back so we can use one bunsen upload.
 valgrind_ltpchecks_step = steps.Test(
         command='make ltpchecks AUX_CHECK_DIR=$HOME/valgrind-auxtests;'
-		+ 'mkdir -p ltplogs;'
-		+ 'cp $HOME/valgrind-auxtests/*/*.log ltplogs;'
-		+ 'cp $HOME/valgrind-auxtests/*/*/*.log ltplogs;',
+		+ 'mv $HOME/valgrind-auxtests/*/valgrind-ltp*log* .;',
         name="make ltpchecks",
         flunkOnFailure=True,
         haltOnFailure=False)
-- 
2.49.0

[Valgrind-developers] [valgrind] FreeBSD regtest: cleanup test warnings when building with GCC

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

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

commit 98d78dde1ffd0848d106d0c1b37476fff9f36fed
Author: Paul Floyd <pj...@wa...>
Date:   Sun May 4 10:38:50 2025 +0200

    FreeBSD regtest: cleanup test warnings when building with GCC

Diff:
---
 drd/tests/thread_name_freebsd.c          |  2 +-
 helgrind/tests/Makefile.am               |  1 +
 massif/tests/Makefile.am                 |  1 +
 memcheck/tests/Makefile.am               |  3 ++-
 memcheck/tests/amd64-freebsd/Makefile.am |  6 +++--
 memcheck/tests/freebsd/Makefile.am       | 46 ++++++++++++++++++++++----------
 memcheck/tests/x86-freebsd/Makefile.am   |  5 ++--
 7 files changed, 44 insertions(+), 20 deletions(-)

diff --git a/drd/tests/thread_name_freebsd.c b/drd/tests/thread_name_freebsd.c
index 0f4954ba7c..dbd342154c 100644
--- a/drd/tests/thread_name_freebsd.c
+++ b/drd/tests/thread_name_freebsd.c
@@ -20,7 +20,7 @@ static void* thread_func(void* argp)
 {
   const int thread_num = (ptrdiff_t)(argp);
   pthread_mutex_t invalid_mutex;
-  char thread_name[32];
+  char thread_name[33];
 
   snprintf(thread_name, sizeof(thread_name),
            "thread_func instance %d", thread_num + 1);
diff --git a/helgrind/tests/Makefile.am b/helgrind/tests/Makefile.am
index 7adc5c6021..817e08a728 100755
--- a/helgrind/tests/Makefile.am
+++ b/helgrind/tests/Makefile.am
@@ -271,6 +271,7 @@ else
 annotate_hbefore_CFLAGS = $(AM_CFLAGS)
 endif
 
+tc09_bad_unlock_CFLAGS = ${AM_CFLAGS} @FLAG_W_NO_UNUSED_BUT_SET_VARIABLE@
 bug322621_SOURCES = bug322621.cpp
 if HAVE_CXX17
 check_PROGRAMS += bug392331
diff --git a/massif/tests/Makefile.am b/massif/tests/Makefile.am
index ab781fa933..d4d798f69c 100644
--- a/massif/tests/Makefile.am
+++ b/massif/tests/Makefile.am
@@ -109,6 +109,7 @@ deep_CFLAGS		= $(AM_CFLAGS) -Wno-unused-result
 ignoring_CFLAGS		= $(AM_CFLAGS) -Wno-unused-result
 insig_CFLAGS		= $(AM_CFLAGS) -Wno-unused-result
 long_names_CFLAGS	= $(AM_CFLAGS) -Wno-unused-result
+malloc_usable_CFLAGS	= ${AM_CFLAGS} @FLAG_W_NO_MAYBE_UNINITIALIZED@
 one_CFLAGS		= $(AM_CFLAGS) -Wno-unused-result
 thresholds_CFLAGS	= $(AM_CFLAGS) -Wno-unused-result
 realloc_CFLAGS		= $(AM_CFLAGS) @FLAG_W_NO_FREE_NONHEAP_OBJECT@
diff --git a/memcheck/tests/Makefile.am b/memcheck/tests/Makefile.am
index bdaa9d761e..401fe8ca8e 100644
--- a/memcheck/tests/Makefile.am
+++ b/memcheck/tests/Makefile.am
@@ -672,8 +672,9 @@ leak_cpp_interior_SOURCES	= leak_cpp_interior.cpp
 # we are actually testing for at runtime.
 accounting_CFLAGS	= $(AM_CFLAGS) @FLAG_W_NO_ALLOC_SIZE_LARGER_THAN@
 badfree_CFLAGS		= $(AM_CFLAGS) @FLAG_W_NO_FREE_NONHEAP_OBJECT@
-bug155125_CFLAGS	= $(AM_CFLAGS) -Wno-unused-result @FLAG_W_NO_ALLOC_SIZE_LARGER_THAN@
+bug155125_CFLAGS	= $(AM_CFLAGS) @FLAG_W_NO_UNUSED_RESULT@ @FLAG_W_NO_ALLOC_SIZE_LARGER_THAN@
 bug472219_CFLAGS	= $(AM_CFLAGS) @FLAG_W_NO_UNINITIALIZED@
+malloc_usable_CFLAGS	= ${AM_CFLAGS} @FLAG_W_NO_MAYBE_UNINITIALIZED@ @FLAG_W_NO_UNINITIALIZED@
 mallinfo_CFLAGS		= $(AM_CFLAGS) -Wno-deprecated-declarations
 malloc3_CFLAGS		= $(AM_CFLAGS) @FLAG_W_NO_ALLOC_SIZE_LARGER_THAN@
 sbfragment_CFLAGS	= $(AM_CFLAGS) -Wno-deprecated-declarations
diff --git a/memcheck/tests/amd64-freebsd/Makefile.am b/memcheck/tests/amd64-freebsd/Makefile.am
index e33607f20e..9f1cefea21 100644
--- a/memcheck/tests/amd64-freebsd/Makefile.am
+++ b/memcheck/tests/amd64-freebsd/Makefile.am
@@ -20,5 +20,7 @@ AM_CFLAGS    += @FLAG_M64@
 AM_CXXFLAGS  += @FLAG_M64@
 AM_CCASFLAGS += @FLAG_M64@
 
-posix_fallocate_CFLAGS       = $(AM_CFLAGS) @FLAG_W_NO_UNINITIALIZED@
-posix_fadvise_CFLAGS       = $(AM_CFLAGS) @FLAG_W_NO_UNINITIALIZED@
+posix_fallocate_CFLAGS	= $(AM_CFLAGS) @FLAG_W_NO_UNINITIALIZED@
+posix_fadvise_CFLAGS	= $(AM_CFLAGS) @FLAG_W_NO_UNINITIALIZED@
+reallocarray_CFLAGS	= ${AM_CFLAGS} @FLAG_W_NO_ALLOC_SIZE_LARGER_THAN@
+
diff --git a/memcheck/tests/freebsd/Makefile.am b/memcheck/tests/freebsd/Makefile.am
index 1213b31898..b362d6148a 100644
--- a/memcheck/tests/freebsd/Makefile.am
+++ b/memcheck/tests/freebsd/Makefile.am
@@ -208,18 +208,36 @@ check_PROGRAMS += timerfd
 timerfd_LDFLAGS = -lm
 endif
 
-aligned_alloc_CFLAGS = ${AM_CFLAGS} @FLAG_W_NO_NON_POWER_OF_TWO_ALIGNMENT@
 
-delete_sized_mismatch_CXXFLAGS = ${AM_CXXFLAGS} --std=c++14
-delete_sized_mismatch_SOURCES = delete_sized_mismatch.cpp
-
-errno_aligned_allocs_CFLAGS = ${AM_CFLAGS} @FLAG_W_NO_NON_POWER_OF_TWO_ALIGNMENT@
-
-
-extattr_CFLAGS = ${AM_CFLAGS} @FLAG_W_NO_UNUSED_BUT_SET_VARIABLE@
-
-memalign_CFLAGS = ${AM_CFLAGS} @FLAG_W_NO_NON_POWER_OF_TWO_ALIGNMENT@
-
-openpty_LDFLAGS = ${AM_LDFLAGS} -lutil
-
-scalar_CFLAGS = ${AM_CFLAGS} -g
+access_CFLAGS 			= ${AM_CFLAGS} @FLAG_W_NO_UNINITIALIZED@ @FLAG_W_NO_USE_AFTER_FREE@
+aligned_alloc_CFLAGS 		= ${AM_CFLAGS} @FLAG_W_NO_NON_POWER_OF_TWO_ALIGNMENT@
+capsicum_CFLAGS 		= ${AM_CFLAGS} @FLAG_W_NO_UNINITIALIZED@ @FLAG_W_NO_USE_AFTER_FREE@
+chflags_CFLAGS 			= ${AM_CFLAGS} @FLAG_W_NO_UNINITIALIZED@ @FLAG_W_NO_USE_AFTER_FREE@
+chmod_chown_CFLAGS 		= ${AM_CFLAGS} @FLAG_W_NO_UNINITIALIZED@ @FLAG_W_NO_USE_AFTER_FREE@
+delete_sized_mismatch_CXXFLAGS	= ${AM_CXXFLAGS} --std=c++14
+delete_sized_mismatch_SOURCES	= delete_sized_mismatch.cpp
+errno_aligned_allocs_CFLAGS	= ${AM_CFLAGS} @FLAG_W_NO_NON_POWER_OF_TWO_ALIGNMENT@
+extattr_CFLAGS			= ${AM_CFLAGS} @FLAG_W_NO_UNUSED_BUT_SET_VARIABLE@ @FLAG_W_NO_UNINITIALIZED@ @FLAG_W_NO_USE_AFTER_FREE@
+get_set_login_CFLAGS		= ${AM_CFLAGS} @FLAG_W_NO_USE_AFTER_FREE@
+getfh_CFLAGS			= ${AM_CFLAGS} @FLAG_W_NO_USE_AFTER_FREE@
+getfsstat_CFLAGS		= ${AM_CFLAGS} @FLAG_W_NO_UNINITIALIZED@ @FLAG_W_NO_USE_AFTER_FREE@
+linkat_CFLAGS			= ${AM_CFLAGS} @FLAG_W_NO_MAYBE_UNINITIALIZED@ @FLAG_W_NO_UNINITIALIZED@ @FLAG_W_NO_USE_AFTER_FREE@
+memalign_CFLAGS			= ${AM_CFLAGS} @FLAG_W_NO_NON_POWER_OF_TWO_ALIGNMENT@
+misc_CFLAGS			= ${AM_CFLAGS} @FLAG_W_NO_USE_AFTER_FREE@
+openpty_LDFLAGS			= ${AM_LDFLAGS} -lutil
+pdfork_pdkill_CFLAGS		= ${AM_CFLAGS} @FLAG_W_NO_MAYBE_UNINITIALIZED@ @FLAG_W_NO_USE_AFTER_FREE@
+realpathat_CFLAGS		= ${AM_CFLAGS} @FLAG_W_NO_USE_AFTER_FREE@
+revoke_CFLAGS			= ${AM_CFLAGS} @FLAG_W_NO_USE_AFTER_FREE@
+scalar_CFLAGS			= ${AM_CFLAGS} -g @FLAG_W_NO_UNINITIALIZED@
+scalar_abort2_CFLAGS		= ${AM_CFLAGS} @FLAG_W_NO_UNINITIALIZED@
+scalar_fork_CFLAGS		= ${AM_CFLAGS} @FLAG_W_NO_UNUSED_VARIABLE@
+scalar_pdfork_CFLAGS		= ${AM_CFLAGS} @FLAG_W_NO_UNINITIALIZED@
+scalar_thr_exit_CFLAGS		= ${AM_CFLAGS} @FLAG_W_NO_UNINITIALIZED@
+scalar_vfork_CFLAGS		= ${AM_CFLAGS} @FLAG_W_NO_UNUSED_VARIABLE@
+sctp2_CFLAGS			= ${AM_CFLAGS} @FLAG_W_NO_UNINITIALIZED@
+sigwait_CFLAGS			= ${AM_CFLAGS} @FLAG_W_NO_USE_AFTER_FREE@
+stat_CFLAGS			= ${AM_CFLAGS} @FLAG_W_NO_MAYBE_UNINITIALIZED@ @FLAG_W_NO_UNINITIALIZED@ @FLAG_W_NO_USE_AFTER_FREE@
+statfs_CFLAGS			= ${AM_CFLAGS} @FLAG_W_NO_UNINITIALIZED@ @FLAG_W_NO_USE_AFTER_FREE@
+timing_safe_CFLAGS		= ${AM_CFLAGS} @FLAG_W_NO_USE_AFTER_FREE@
+utimens_CFLAGS			= ${AM_CFLAGS} @FLAG_W_NO_UNINITIALIZED@ @FLAG_W_NO_USE_AFTER_FREE@
+utimes_CFLAGS			= ${AM_CFLAGS} @FLAG_W_NO_UNINITIALIZED@ @FLAG_W_NO_USE_AFTER_FREE@
diff --git a/memcheck/tests/x86-freebsd/Makefile.am b/memcheck/tests/x86-freebsd/Makefile.am
index 913914a043..1d8069021b 100644
--- a/memcheck/tests/x86-freebsd/Makefile.am
+++ b/memcheck/tests/x86-freebsd/Makefile.am
@@ -19,5 +19,6 @@ AM_CFLAGS    += @FLAG_M32@
 AM_CXXFLAGS  += @FLAG_M32@
 AM_CCASFLAGS += @FLAG_M32@
 
-posix_fallocate_CFLAGS       = $(AM_CFLAGS) @FLAG_W_NO_UNINITIALIZED@
-posix_fadvise_CFLAGS       = $(AM_CFLAGS) @FLAG_W_NO_UNINITIALIZED@
+posix_fallocate_CFLAGS	= $(AM_CFLAGS) @FLAG_W_NO_UNINITIALIZED@
+posix_fadvise_CFLAGS	= $(AM_CFLAGS) @FLAG_W_NO_UNINITIALIZED@
+reallocarray_CFLAGS	= ${AM_CFLAGS} @FLAG_W_NO_ALLOC_SIZE_LARGER_THAN@

[Valgrind-developers] [valgrind] Bug 503677 - duplicated-cond compiler warning in dis_RV64M

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

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

commit 09c161e6e0ee8ee057d81cfb71c0d98b16f36a19
Author: Paul Floyd <pj...@wa...>
Date:   Sun May 4 08:55:45 2025 +0200

    Bug 503677 - duplicated-cond compiler warning in dis_RV64M

Diff:
---
 NEWS                          | 1 +
 VEX/priv/guest_riscv64_toIR.c | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index 71c389c535..b69dc84f8b 100644
--- a/NEWS
+++ b/NEWS
@@ -24,6 +24,7 @@ than mailing the developers (or mailing lists) directly -- bugs that
 are not entered into bugzilla tend to get forgotten about or ignored.
 
 503641  close_range syscalls started failing with 3.25.0
+503677  duplicated-cond compiler warning in dis_RV64M
 
 To see details of a given bug, visit
   https://bugs.kde.org/show_bug.cgi?id=XXXXXX
diff --git a/VEX/priv/guest_riscv64_toIR.c b/VEX/priv/guest_riscv64_toIR.c
index 5d9b903c9b..393a7ca7d0 100644
--- a/VEX/priv/guest_riscv64_toIR.c
+++ b/VEX/priv/guest_riscv64_toIR.c
@@ -1754,8 +1754,6 @@ static Bool dis_RV64M(/*MB_OUT*/ DisResult* dres,
       UInt rs1    = INSN(19, 15);
       UInt rs2    = INSN(24, 20);
       if (funct3 == 0b010) {
-         /* Invalid {MUL,DIV,REM}<x>, fall through. */
-      } else if (funct3 == 0b010) {
          /* MULHSU, not currently handled, fall through. */
       } else {
          if (rd != 0) {

[Valgrind-developers] [COMMITTED] Add valgrind_ltpchecks_step

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

We only have .log files so copy them into to builddir so they get
picked up by the bunsen upload.
---
 builder/master.cfg | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/builder/master.cfg b/builder/master.cfg
index eed4b7636ab0..26d13fa60b1b 100644
--- a/builder/master.cfg
+++ b/builder/master.cfg
@@ -4947,6 +4947,17 @@ valgrind_regtest_step = steps.Test(
         flunkOnFailure=True,
         haltOnFailure=False)
 
+# Note we use command as string so it gets passed to /bin/sh -c
+# And we just copy the logs back so we can use one bunsen upload.
+valgrind_ltpchecks_step = steps.Test(
+        command='make ltpchecks AUX_CHECK_DIR=$HOME/valgrind-auxtests;'
+		+ 'mkdir -p ltplogs;'
+		+ 'cp $HOME/valgrind-auxtests/*/*.log ltplogs;'
+		+ 'cp $HOME/valgrind-auxtests/*/*/*.log ltplogs;',
+        name="make ltpchecks",
+        flunkOnFailure=True,
+        haltOnFailure=False)
+
 valgrind_make_all_docs_step = steps.Compile(
         name="make all-docs",
         command=["make", "-C", "docs", "all-docs"])
@@ -4977,6 +4988,7 @@ valgrind_dist_factory.addStep(configure_step)
 valgrind_dist_factory.addStep(make_step)
 valgrind_dist_factory.addStep(make_check_step)
 valgrind_dist_factory.addStep(valgrind_regtest_step)
+valgrind_dist_factory.addStep(valgrind_ltpchecks_step)
 valgrind_dist_factory.addSteps(bunsen_logfile_upload_cpio_steps(["*.sum", "*.log", "*.trs"]))
 valgrind_dist_factory.addStep(make_distcheck_step)
 valgrind_dist_factory.addStep(make_distclean_step)
@@ -4988,6 +5000,7 @@ valgrind_make_check_factory.addStep(configure_step)
 valgrind_make_check_factory.addStep(make_step)
 valgrind_make_check_factory.addStep(make_check_step)
 valgrind_make_check_factory.addStep(valgrind_regtest_step)
+valgrind_make_check_factory.addStep(valgrind_ltpchecks_step)
 valgrind_make_check_factory.addSteps(bunsen_logfile_upload_cpio_steps(["*.sum", "*.log", "*.trs"]))
 valgrind_make_check_factory.addStep(make_distclean_step)
 
-- 
2.49.0

Re: [Valgrind-developers] Next version numbering

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

On 02-05-25 08:22, Florian Krohm wrote:
> On 02.05.25 10:02, Nicholas Nethercote wrote:
>> I like the existing numbering, and I don't see a strong reason to change
>> what has worked for a long time.
>>
> 
> +1

OK, 3.26 it is/will be.

A+
Paul

[Valgrind-developers] [valgrind] Bug 503641 - close_range syscalls started failing with 3.25.0

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

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

commit 933e542b431f17681cc915de656e853dc16d4fe7
Author: Paul Floyd <pj...@wa...>
Date:   Fri May 2 18:53:09 2025 +0200

    Bug 503641 - close_range syscalls started failing with 3.25.0

Diff:
---
 NEWS                                        |  1 +
 coregrind/m_syswrap/syswrap-linux.c         | 58 ++++++++++++++---------------
 memcheck/tests/close_range.stderr.exp.linux |  6 +--
 3 files changed, 33 insertions(+), 32 deletions(-)

diff --git a/NEWS b/NEWS
index 6a15080c15..71c389c535 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.
 
+503641  close_range syscalls started failing with 3.25.0
 
 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 de710c97e4..6f3917830f 100644
--- a/coregrind/m_syswrap/syswrap-linux.c
+++ b/coregrind/m_syswrap/syswrap-linux.c
@@ -13699,17 +13699,20 @@ PRE(sys_execveat)
 
 PRE(sys_close_range)
 {
-   SysRes res = VG_(mk_SysRes_Success)(0);
-   Int beg, end;
-   Int first = ARG1;
-   Int last = ARG2;
+   UInt first = ARG1;
+   UInt last = ARG2;
+
+   vg_assert(VG_(log_output_sink).fd == -1 ||
+             VG_(log_output_sink).fd >= VG_(fd_hard_limit));
+   vg_assert(VG_(xml_output_sink).fd == -1 ||
+             VG_(xml_output_sink).fd >= VG_(fd_hard_limit));
 
    FUSE_COMPATIBLE_MAY_BLOCK();
    PRINT("sys_close_range ( %" FMT_REGWORD "u, %" FMT_REGWORD "u, %"
          FMT_REGWORD "u )", ARG1, ARG2, ARG3);
    PRE_REG_READ3(long, "close_range",
                  unsigned int, first, unsigned int, last,
-                 unsigned int, flags);
+                 int, flags);
 
    if (first > last) {
       SET_STATUS_Failure( VKI_EINVAL );
@@ -13724,29 +13727,28 @@ PRE(sys_close_range)
       return;
    }
 
-   beg = end = first;
-   do {
-      if (end > last
-	  || (end == 2/*stderr*/ && VG_(debugLog_getLevel)() > 0)
-	  || end == VG_(log_output_sink).fd
-	  || end == VG_(xml_output_sink).fd) {
-         /* Split the range if it contains a file descriptor we're not
-          * supposed to close. */
-         if (end - 1 >= beg)
-             res = VG_(do_syscall3)(__NR_close_range, (UWord)beg, (UWord)end - 1, ARG3 );
-         beg = end + 1;
+   if (VG_(debugLog_getLevel)() > 0 &&
+      first <= 2U &&
+      last >= 2U &&
+      first != last) {
+      SysRes res = VG_(mk_SysRes_Success)(0);
+      if (first <= 1U) {
+         res = VG_(do_syscall3)(__NR_close_range, first, 1U, ARG3);
       }
-   } while (end++ <= last);
-
-   /* If it failed along the way, it's presumably the flags being wrong. */
-   SET_STATUS_from_SysRes (res);
+      if (!sr_isError(res) && last >= 3U) {
+         res = VG_(do_syscall3)(__NR_close_range, 3U, last, ARG3);
+      }
+      /* If it failed along the way, it's presumably the flags being wrong. */
+      SET_STATUS_from_SysRes (res);
+   } else {
+      SET_STATUS_from_SysRes(VG_(do_syscall3)(__NR_close_range, first, last, ARG3));
+   }
 }
 
 POST(sys_close_range)
 {
-   Int fd;
-   Int first = ARG1;
-   Int last = ARG2;
+   UInt fd;
+   UInt last = ARG2;
 
    if (!VG_(clo_track_fds)
        || (ARG3 & VKI_CLOSE_RANGE_CLOEXEC) != 0)
@@ -13757,13 +13759,11 @@ POST(sys_close_range)
 
    /* If the close_range range is too wide, we don't want to loop
       through the whole range.  */
-   if (last == ~0U)
-     ML_(record_fd_close_range)(tid, first);
+   if (ARG2 >= VG_(fd_hard_limit))
+     ML_(record_fd_close_range)(tid, ARG1);
    else {
-     for (fd = first; fd <= last; fd++)
-       if ((fd != 2/*stderr*/ || VG_(debugLog_getLevel)() == 0)
-           && fd != VG_(log_output_sink).fd
-           && fd != VG_(xml_output_sink).fd)
+     for (fd = ARG1; fd <= last; fd++)
+       if ((fd != 2/*stderr*/ || VG_(debugLog_getLevel)() == 0))
          ML_(record_fd_close)(tid, fd);
    }
 }
diff --git a/memcheck/tests/close_range.stderr.exp.linux b/memcheck/tests/close_range.stderr.exp.linux
index 3a0de7837a..93c4bfa270 100644
--- a/memcheck/tests/close_range.stderr.exp.linux
+++ b/memcheck/tests/close_range.stderr.exp.linux
@@ -1,12 +1,12 @@
 Syscall param close_range(first) contains uninitialised byte(s)
    at 0x........: close_range (in /...libc...)
-   by 0x........: main (close_range.c:89)
+   by 0x........: main (close_range.c:92)
 
 Syscall param close_range(last) contains uninitialised byte(s)
    at 0x........: close_range (in /...libc...)
-   by 0x........: main (close_range.c:89)
+   by 0x........: main (close_range.c:92)
 
 Syscall param close_range(flags) contains uninitialised byte(s)
    at 0x........: close_range (in /...libc...)
-   by 0x........: main (close_range.c:89)
+   by 0x........: main (close_range.c:92)

[Valgrind-developers] [valgrind] FreeBSD close_range syscall

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

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

commit 8edc2fa6f8d70dbe10d634adff2513aa68143a22
Author: Paul Floyd <pj...@wa...>
Date:   Fri May 2 16:59:58 2025 +0200

    FreeBSD close_range syscall
    
    Simplify the checking. No ned to test for reserved fds,
    and just split the close_range if debug output is enabled.
    
    Add a call to close_range with an upper bound of ~0U in the
    testcase.
    
    These changes will probably be the basis for fixing
    https://bugs.kde.org/show_bug.cgi?id=503641

Diff:
---
 coregrind/m_syswrap/syswrap-freebsd.c | 62 +++++++++++++++++------------------
 memcheck/tests/close_range.c          |  5 ++-
 memcheck/tests/close_range.stderr.exp |  6 ++--
 3 files changed, 38 insertions(+), 35 deletions(-)

diff --git a/coregrind/m_syswrap/syswrap-freebsd.c b/coregrind/m_syswrap/syswrap-freebsd.c
index 7ea04fdbc6..41cd075619 100644
--- a/coregrind/m_syswrap/syswrap-freebsd.c
+++ b/coregrind/m_syswrap/syswrap-freebsd.c
@@ -6615,10 +6615,8 @@ POST(sys___realpathat)
 // int close_range(u_int lowfd, u_int highfd, int flags);
 PRE(sys_close_range)
 {
-   SysRes res = VG_(mk_SysRes_Success)(0);
-   unsigned int lowfd = ARG1;
-   unsigned int fd_counter; // will count from lowfd to highfd
-   unsigned int highfd = ARG2;
+   UInt lowfd = ARG1;
+   UInt highfd = ARG2;
 
    /* on linux the may lock if futexes are used
     * there is a lock in the kernel but I assume it's just
@@ -6642,46 +6640,48 @@ PRE(sys_close_range)
       return;
    }
 
-   fd_counter = lowfd;
-   do {
-      if (fd_counter > highfd
-          || (fd_counter == 2U/*stderr*/ && VG_(debugLog_getLevel)() > 0)
-          || fd_counter == VG_(log_output_sink).fd
-          || fd_counter == VG_(xml_output_sink).fd) {
-         /* Split the range if it contains a file descriptor we're not
-          * supposed to close. */
-         if (fd_counter - 1 >= lowfd) {
-            res = VG_(do_syscall3)(__NR_close_range, (UWord)lowfd, (UWord)fd_counter - 1, ARG3 );
-         }
-         lowfd = fd_counter + 1;
-      }
-   } while (fd_counter++ <= highfd);
+   vg_assert(VG_(log_output_sink).fd == -1 ||
+             VG_(log_output_sink).fd >= VG_(fd_hard_limit));
+   vg_assert(VG_(xml_output_sink).fd == -1 ||
+             VG_(xml_output_sink).fd >= VG_(fd_hard_limit));
 
-   /* If it failed along the way, it's presumably the flags being wrong. */
-   SET_STATUS_from_SysRes (res);
+   if (VG_(debugLog_getLevel)() > 0 &&
+      lowfd <= 2U &&
+      highfd >= 2U &&
+      lowfd != highfd) {
+      SysRes res = VG_(mk_SysRes_Success)(0);
+      if (lowfd <= 1U) {
+         res = VG_(do_syscall3)(__NR_close_range, lowfd, 1U, ARG3);
+      }
+      if (!sr_isError(res) && highfd >= 3U) {
+         res = VG_(do_syscall3)(__NR_close_range, 3U, highfd, ARG3);
+      }
+      /* If it failed along the way, it's presumably the flags being wrong. */
+      SET_STATUS_from_SysRes (res);
+   } else {
+      SET_STATUS_from_SysRes(VG_(do_syscall3)(__NR_close_range, lowfd, highfd, ARG3));
+   }
 }
 
 POST(sys_close_range)
 {
-   unsigned int fd;
-   unsigned int last = ARG2;
+   UInt fd;
+   UInt highfd = ARG2;
 
    if (!VG_(clo_track_fds)
        || (ARG3 & VKI_CLOSE_RANGE_CLOEXEC) != 0)
       return;
 
-   if (last >= VG_(fd_hard_limit))
-      last = VG_(fd_hard_limit) - 1;
+   if (highfd >= VG_(fd_hard_limit))
+       highfd = VG_(fd_hard_limit) - 1;
 
    /* If the close_range range is too wide, we don't want to loop
       through the whole range.  */
-   if (ARG2 == ~0U)
-     ML_(record_fd_close_range)(tid, ARG1);
-   else {
-      for (fd = ARG1; fd <= last; fd++)
-         if ((fd != 2/*stderr*/ || VG_(debugLog_getLevel)() == 0)
-             && fd != VG_(log_output_sink).fd
-             && fd != VG_(xml_output_sink).fd)
+   if (ARG2 >= VG_(fd_hard_limit)) {
+      ML_(record_fd_close_range)(tid, ARG1);
+   } else {
+      for (fd = ARG1; fd <= highfd; fd++)
+         if ((fd != 2/*stderr*/ || VG_(debugLog_getLevel)() == 0))
             ML_(record_fd_close)(tid, fd);
    }
 }
diff --git a/memcheck/tests/close_range.c b/memcheck/tests/close_range.c
index 6d8b5a0ba8..5c21e7f42b 100644
--- a/memcheck/tests/close_range.c
+++ b/memcheck/tests/close_range.c
@@ -65,7 +65,7 @@ int main(void)
    
    errno = 0;
    // wrong order
-   close_range(fd3, fd1, 2);
+   close_range(fd3, fd1, 0);
    assert(errno = EINVAL);
    
    errno = 0;
@@ -82,6 +82,9 @@ int main(void)
    
    close_range(3, rl.rlim_cur+1, 0);
    
+   int res = close_range(2U, ~0U, 0);
+   assert(res == 0);
+   
    {
       unsigned a;
       unsigned b;
diff --git a/memcheck/tests/close_range.stderr.exp b/memcheck/tests/close_range.stderr.exp
index 2f4d018f22..51dfcd40a5 100644
--- a/memcheck/tests/close_range.stderr.exp
+++ b/memcheck/tests/close_range.stderr.exp
@@ -1,12 +1,12 @@
 Syscall param close_range(lowfd) contains uninitialised byte(s)
    at 0x........: close_range (in /...libc...)
-   by 0x........: main (close_range.c:89)
+   by 0x........: main (close_range.c:92)
 
 Syscall param close_range(highfd) contains uninitialised byte(s)
    at 0x........: close_range (in /...libc...)
-   by 0x........: main (close_range.c:89)
+   by 0x........: main (close_range.c:92)
 
 Syscall param close_range(flags) contains uninitialised byte(s)
    at 0x........: close_range (in /...libc...)
-   by 0x........: main (close_range.c:89)
+   by 0x........: main (close_range.c:92)

[Valgrind-developers] [valgrind] illumos regtest: filter a gdb warning

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

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

commit f54b622a8f60006317abdb54d4fd9dfe0936d421
Author: Paul Floyd <pj...@wa...>
Date:   Fri May 2 12:19:11 2025 +0200

    illumos regtest: filter a gdb warning
    
    I only get it when running make test from oi-userland components,
    not when running make regtest from a shell. Possibly a locale or
    similar issue.

Diff:
---
 NEWS                          | 30 ++++++++++++++++++++++++++++++
 configure.ac                  |  6 +++---
 gdbserver_tests/filter_gdb.in |  3 +++
 3 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/NEWS b/NEWS
index cd4670aca6..6a15080c15 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,33 @@
+Release 3.26.0 (?? Oct 2025)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux,
+PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux,
+MIPS64/Linux, RISCV64/Linux, ARM/Android, ARM64/Android, MIPS32/Android,
+X86/Android, X86/Solaris, AMD64/Solaris, AMD64/MacOSX 10.12, X86/FreeBSD,
+AMD64/FreeBSD and ARM64/FreeBSD There is also preliminary support for
+X86/macOS 10.13, AMD64/macOS 10.13 and nanoMIPS/Linux.
+
+* ==================== CORE CHANGES ===================
+
+* ================== PLATFORM CHANGES =================
+
+* ==================== TOOL CHANGES ===================
+
+* ==================== FIXED BUGS ====================
+
+The following bugs have been fixed or resolved.  Note that "n-i-bz"
+stands for "not in bugzilla" -- that is, a bug that was reported to us
+but never got a bugzilla entry.  We encourage you to file bugs in
+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.
+
+
+To see details of a given bug, visit
+  https://bugs.kde.org/show_bug.cgi?id=XXXXXX
+where XXXXXX is the bug number as listed above.
+
 Release 3.25.0 (25 Apr 2025)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
diff --git a/configure.ac b/configure.ac
index 2dfbd1c1af..84a69f810e 100755
--- a/configure.ac
+++ b/configure.ac
@@ -16,10 +16,10 @@ AC_PREREQ(2.69)
 # Also set the (expected/last) release date here.
 # Do not forget to rerun ./autogen.sh
 m4_define([v_major_ver], [3])
-m4_define([v_minor_ver], [25])
+m4_define([v_minor_ver], [26])
 m4_define([v_micro_ver], [0])
-m4_define([v_suffix_ver], [])
-m4_define([v_rel_date], ["25 Apr 2025"])
+m4_define([v_suffix_ver], [GIT])
+m4_define([v_rel_date], ["?? Oct 2025"])
 m4_define([v_version],
 	  m4_if(v_suffix_ver, [],
 		[v_major_ver.v_minor_ver.v_micro_ver],
diff --git a/gdbserver_tests/filter_gdb.in b/gdbserver_tests/filter_gdb.in
index d7b1bb11c6..7f7862a889 100755
--- a/gdbserver_tests/filter_gdb.in
+++ b/gdbserver_tests/filter_gdb.in
@@ -276,6 +276,9 @@ s/^0x........ in \(\w\+ (\)/\1/
 /^Missing debuginfo.*/d
 /^Missing rpms.*/d
 
+#	illumos, but only when building the port
+/\.\/gdb: warning: Couldn't determine a path for the index cache directory\./d
+
 EOF
 
 dir=`dirname $0`

Re: [Valgrind-developers] Next version numbering

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

On 02.05.25 10:02, Nicholas Nethercote wrote:
> I like the existing numbering, and I don't see a strong reason to change
> what has worked for a long time.
> 

+1

   Florian

Re: [Valgrind-developers] Next version numbering

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

I like the existing numbering, and I don't see a strong reason to change
what has worked for a long time.

Nick

On Thu, 1 May 2025 at 18:14, Philippe Waroquiers via Valgrind-developers <
val...@li...> wrote:

> On Thu, 2025-05-01 at 09:40 +0200, Paul Floyd via Valgrind-developers
> wrote:
> > Hi all
> >
> > I've been wondering whether we should switch to a year based numbering
> > scheme rather than our current semantic versioning. I'm not sure if
> > there will ever be a version 4. Making Valgrind multithreaded would
> > warrant such a change but I can't see that happening.
>
> I did an experimental multithreaded trial some years ago, the prototype
> could run
> the none tool multi-threaded, so valgrind was able to do nothing faster :).
> But this stopped when I found no solution for memcheck.
>
> I still believe a multi-threaded valgrind is relevant for some tools such
> as callgrind
> that do not depend (too much) on a "central data structure accessed on a
> permanent basis".
>
> And maybe new things/instructions such as rseq might maybe provide a
> solution for memcheck
> (avoiding the performance killer to protect the memcheck V bits
> infrastructure for any
> access done by the guest).
>
> But I agree with you that it is unlikely to appear very soon. On my side,
> I am not
> expecting to have time to work on that prototype before I am retired
> (but this time gets closer every day :).
>
> >
> > What I'm thinking of is 2025.04, 2025.10 etc.
> >
> > Thoughts?
>
> On this aspect, I do not have strong preference but the "year" based
> approach makes
> more clear when someone complains that they are using a (very) old release.
>
> >
> > A+
> >
> > Paul
> >
> >
> >
> >
> > _______________________________________________
> > Valgrind-developers mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
>
>
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>

Re: [Valgrind-developers] Next version numbering

[Philippe W. <phi...@sk...>]

On Thu, 2025-05-01 at 09:40 +0200, Paul Floyd via Valgrind-developers wrote:
> Hi all
> 
> I've been wondering whether we should switch to a year based numbering 
> scheme rather than our current semantic versioning. I'm not sure if 
> there will ever be a version 4. Making Valgrind multithreaded would 
> warrant such a change but I can't see that happening.

I did an experimental multithreaded trial some years ago, the prototype could run
the none tool multi-threaded, so valgrind was able to do nothing faster :).
But this stopped when I found no solution for memcheck.

I still believe a multi-threaded valgrind is relevant for some tools such as callgrind
that do not depend (too much) on a "central data structure accessed on a permanent basis".

And maybe new things/instructions such as rseq might maybe provide a solution for memcheck
(avoiding the performance killer to protect the memcheck V bits infrastructure for any
access done by the guest).

But I agree with you that it is unlikely to appear very soon. On my side, I am not
expecting to have time to work on that prototype before I am retired
(but this time gets closer every day :).

> 
> What I'm thinking of is 2025.04, 2025.10 etc.
> 
> Thoughts?

On this aspect, I do not have strong preference but the "year" based approach makes
more clear when someone complains that they are using a (very) old release.

> 
> A+
> 
> Paul
> 
> 
> 
> 
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers