Do you get the error from a clean clone of Valgrind?

If it’s from an old git repo, does running ‘make distclean’ and ‘autogen.sh’ then configure and make work?

Almost certainly the problem is that VEX/pub/libvex_guest_mips{32,64}.h are missing U{Int,Long} guest_IP_AT_SYSCALL plus maybe something to initialize them.

I used clean source from tarball:

wget https://sourceware.org/pub/valgrind/valgrind-3.23.0.tar.bz2
tar xf valgrind-3.23.0.tar.bz2
cd valgrind-3.23.0
./configure --host=mipsel-linux --target=mipsel-linux
make

m_scheduler/scheduler.c: In function ���handle_extension���:
m_scheduler/scheduler.c:1238:32: error: ���VexGuestArchState��� {aka ���struct <anonymous>���} has no member named ���guest_IP_AT_SYSCALL���
       Addr addr = tst->arch.vex.guest_IP_AT_SYSCALL;
                                ^
make[3]: *** [Makefile:6562: m_scheduler/libcoregrind_mips64_linux_a-scheduler.o] Error 1
make[3]: Leaving directory '/home/paulf/valgrind/coregrind'
make[2]: *** [Makefile:2557: all] Error 2
make[2]: Leaving directory '/home/paulf/valgrind/coregrind'
make[1]: *** [Makefile:918: all-recursive] Error 1
make[1]: Leaving directory '/home/paulf/valgrind'
make: *** [Makefile:781: all] Error 2

on mips32

Urgh, this is unfortunate. We didn't have a mips builder and didn't find this during CI testing.

This should probably have been implemented as VG_(client_extension) see coregrind/m_extension/extension-main.c which is only done for s390x now.

There is precedent in fixup_guest_state_to_restart_syscall

I tested the build on a mips32 machine. Can you please also confirm mips64?

commit 7214886886bce9029f325214156c02dcfff760d5 (HEAD -> master, origin/master, origin/HEAD)
Author: Paul Floyd <pjfloyd@wanadoo.fr>
Date:   Sat Apr 27 13:07:07 2024 +0200

    486180  - [Valgrind][MIPS] 'VexGuestArchState' has no member named 'guest_IP_AT_SYSCALL'

I don't really like the suggested fix in comment #6 (commit 721488688).
It is not clear to me that all arches use guest_IP_AT_SYSCALL is the same way.
The current use only really is known to work for s390x.

So I would propose something like:

diff --git a/coregrind/m_scheduler/scheduler.c b/coregrind/m_scheduler/scheduler.c
index fc8cf7c9cb1d..6ce3551b2be9 100644
--- a/coregrind/m_scheduler/scheduler.c
+++ b/coregrind/m_scheduler/scheduler.c
@@ -1225,6 +1225,15 @@ static void handle_syscall(ThreadId tid, UInt trc)
    }
 }
 
+static Addr sig_ill_addr_extension (ThreadState *tst)
+{
+#if defined(VGA_s390x)
+   return tst->arch.vex.guest_IP_AT_SYSCALL;
+#else
+   VG_(core_panic)("scheduler: sig_ill_addr_extension: unhandled arch");
+#endif
+}
+
 static void handle_extension(ThreadId tid)
 {
    volatile UWord jumped;
@@ -1235,7 +1244,7 @@ static void handle_extension(ThreadId tid)
 
    if (err != ExtErr_OK) {
       ThreadState* tst = VG_(get_ThreadState)(tid);
-      Addr addr = tst->arch.vex.guest_IP_AT_SYSCALL;
+      Addr addr = sig_ill_addr_extension (tst);
       switch (err) {
       case ExtErr_Illop:
          VG_(synth_sigill)(tid, addr);

(In reply to Mark Wielaard from comment #7)
> The current use only really is known to work for s390x.
The use for the extension mechanism, yes.  But I was under the impression that this field is required for all architectures that use Ijk_Sys_syscall and friends (which I thought included all arches). Consider the comment in libvex_ir.h:

   Re Ijk_Sys_ (syscall jumps): the guest state must have a
   pseudo-register guest_IP_AT_SYSCALL, which is the size of a guest
   word.  ...

However, now I'm not sure where the field is actually used, apart from the new usage in handle_extension().  Does anybody know more about this?

> So I would propose something like:
> [...]

That's an option, although I prefer to get rid of this altogether and just use VG_(get_IP), like below.  Now I'm wondering why I haven't done
that before.  Is this OK?

diff --git a/coregrind/m_scheduler/scheduler.c b/coregrind/m_scheduler/scheduler.c
index 29751bb28..cc8d070b7 100644
--- a/coregrind/m_scheduler/scheduler.c
+++ b/coregrind/m_scheduler/scheduler.c
@@ -1237,8 +1237,7 @@ static void handle_extension(ThreadId tid)
       block_signals();
       VG_(poll_signals)(tid);
    } else if (err != ExtErr_OK) {
-      ThreadState* tst = VG_(get_ThreadState)(tid);
-      Addr addr = tst->arch.vex.guest_IP_AT_SYSCALL;
+      Addr addr = VG_(get_IP)(tid);
       switch (err) {
       case ExtErr_Illop:
          VG_(synth_sigill)(tid, addr);

I really wonder if this is needed on other platforms.

Looking at the use prior to the new s390 code, VEX stores the program counter on ppc and x86 but it was only used for Darwin on x86 and amd64. I can't easily check Darwin x86 as the last working version was 10.12 and, well, who cares about x86 Darwin? Apple removed x86 support with 10.15. If the Darwin port ever gets fixed we should probably remove x86 Darwin.

amd64 Darwin looks like it only ever intializes the VEX field to 0 but then it uses it in ML_(fixup_guest_state_to_restart_syscall). That might explain a few of the several hundred Darwin regtest failures. All other OSes just subtract the size of the syscall opcode from the program counter.