Provide a module for `clear_cache'

Provide a module for `clear_cache'

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

The idea is to offer the builtin procedure

__builtin__clear_cache (void *begin, void *end),

which is provided at least by gcc and clang, in a portable manner.  From
the documentation of gcc's version:

"This function is used to flush the processor’s instruction cache for the
region of memory between begin inclusive and end exclusive. Some targets
require that the instruction cache be flushed, after modifying memory
containing code, in order to obtain deterministic behavior."

Clients for such a procedure are, in particular, JIT compilers.  GNU
lightning currently calls libgcc's `__clear_cache' directly ([1]), but this
will fail on systems that do not have libgcc.

Having a Gnulib module that tests for the builtin analogous to the module
`builtin-expect' ([2]) would be great.
Thanks,

Marc

--

[1] --
https://git.savannah.gnu.org/cgit/lightning.git/tree/lib/jit_aarch64.c#n73
[2] --
https://www.gnu.org/software/gnulib/MODULES.html#module=builtin-expect

[-- Attachment #2: Type: text/html, Size: 2513 bytes --]

Re: Provide a module for `clear_cache'

[Bruno Haible]

Hello Marc,

> The idea is to offer the builtin procedure
> 
> __builtin__clear_cache (void *begin, void *end),
> 
> which is provided at least by gcc and clang, in a portable manner.  From
> the documentation of gcc's version:
> 
> "This function is used to flush the processor’s instruction cache for the
> region of memory between begin inclusive and end exclusive. Some targets
> require that the instruction cache be flushed, after modifying memory
> containing code, in order to obtain deterministic behavior."
> 
> Clients for such a procedure are, in particular, JIT compilers.

I can provide such a thing easily. In fact, I have it already sitting
around on my disk since 2021 :-)

> GNU
> lightning currently calls libgcc's `__clear_cache' directly ([1]), but this
> will fail on systems that do not have libgcc.

And also, libgcc's __clear_cache does not always work. My comments say:

  /* GCC >= 4.3 has a GCC built-in.
     <https://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Other-Builtins.html>
     But it's sometimes not correctly implemented.

So, I can provide the module's code. Can you provide a unit test for it?

Bruno

Re: Provide a module for `clear_cache'

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

Hello Bruno,

Am Mo., 6. Nov. 2023 um 19:33 Uhr schrieb Bruno Haible <bruno@clisp.org>:

[...]

I can provide such a thing easily. In fact, I have it already sitting
> around on my disk since 2021 :-)
>

This is great!


> > GNU
> > lightning currently calls libgcc's `__clear_cache' directly ([1]), but
> this
> > will fail on systems that do not have libgcc.
>
> And also, libgcc's __clear_cache does not always work. My comments say:
>
>   /* GCC >= 4.3 has a GCC built-in.
>      <https://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Other-Builtins.html>
>      But it's sometimes not correctly implemented.
>
> So, I can provide the module's code. Can you provide a unit test for it?
>

I only have access to x86_64 systems, for which `clear_cache ()' can be a
no-op.  Emulators aren't of much help because they usually do not implement
the need for cache invalidation faithfully.  We would need the help of
someone with, say, an Aarch64 system.

If we want to support a wider variety of systems, the code of Chez Scheme
may be helpful.  The `S_doflush' function ([1]) does the cache clearing.

--

[1]
https://github.com/search?q=repo%3Acisco%2FChezScheme%20S_doflush&type=code

[-- Attachment #2: Type: text/html, Size: 2739 bytes --]

Re: test environments

[Bruno Haible]

Marc Nieper-Wißkirchen wrote:
> I only have access to x86_64 systems, for which `clear_cache ()' can be a
> no-op.  Emulators aren't of much help because they usually do not implement
> the need for cache invalidation faithfully.  We would need the help of
> someone with, say, an Aarch64 system.

I've added info about how to get access to test environments here:
  https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=blob;f=platforms/test-environments.txt
  https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=tree;f=platforms/environments

In particular, the compile farm has 4 machines with aarch64 CPU.
Maybe you also have an Android phone with aarch64 CPU on it (and
can install Termux in 64-bit mode on it)?

It is correct that emulators sometimes don't implement the need for
cache invalidation correctly; I observed this for mips too. But QEMU
is quite good nowadays; it's better than nothing.

Bruno

new module 'jit/cache'

[Bruno Haible]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

Marc Nieper-Wißkirchen wrote:
> I can provide such a thing easily. In fact, I have it already sitting
> > around on my disk since 2021 :-)
> >
> 
> This is great!

I'm adding the new module, below.

> If we want to support a wider variety of systems, the code of Chez Scheme
> may be helpful.  The `S_doflush' function ([1]) does the cache clearing.
> 
> [1]
> https://github.com/search?q=repo%3Acisco%2FChezScheme%20S_doflush&type=code

Thanks. It appears to be more optimized than what I have on Linux/arm64,
but optimizations are dangerous, you know...


2023-11-12  Bruno Haible  <bruno@clisp.org>

	jit/cache: New module.
	* lib/jit/cache.h: New file.
	* m4/valgrind-helper.m4: New file.
	* modules/jit/cache: New file.


[-- Attachment #2: 0001-jit-cache-New-module.patch --]
[-- Type: text/x-patch, Size: 8325 bytes --]

From f48984f04a9649727f1d0b0f4fd25e88924f9c42 Mon Sep 17 00:00:00 2001
From: Bruno Haible <bruno@clisp.org>
Date: Sun, 12 Nov 2023 18:22:50 +0100
Subject: [PATCH] jit/cache: New module.

* lib/jit/cache.h: New file.
* m4/valgrind-helper.m4: New file.
* modules/jit/cache: New file.
---
 ChangeLog             |   7 +++
 lib/jit/cache.h       | 140 ++++++++++++++++++++++++++++++++++++++++++
 m4/valgrind-helper.m4 |  22 +++++++
 modules/jit/cache     |  24 ++++++++
 4 files changed, 193 insertions(+)
 create mode 100644 lib/jit/cache.h
 create mode 100644 m4/valgrind-helper.m4
 create mode 100644 modules/jit/cache

diff --git a/ChangeLog b/ChangeLog
index c2a59f8f88..c7fa04a173 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2023-11-12  Bruno Haible  <bruno@clisp.org>
+
+	jit/cache: New module.
+	* lib/jit/cache.h: New file.
+	* m4/valgrind-helper.m4: New file.
+	* modules/jit/cache: New file.
+
 2023-11-11  Bruno Haible  <bruno@clisp.org>
 
 	ssfmalloc: Take advantage of CHERI bounds-checking.
diff --git a/lib/jit/cache.h b/lib/jit/cache.h
new file mode 100644
index 0000000000..ce470399e5
--- /dev/null
+++ b/lib/jit/cache.h
@@ -0,0 +1,140 @@
+/* JIT compiler - Flushing the instruction cache.
+
+   Copyright (C) 1995-2023 Free Software Foundation, Inc.
+
+   This file is free software: you can redistribute it and/or modify
+   it under the terms of the GNU Lesser General Public License as
+   published by the Free Software Foundation; either version 2.1 of the
+   License, or (at your option) any later version.
+
+   This file is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public License
+   along with this program.  If not, see <https://www.gnu.org/licenses/>.  */
+
+/* Written by Bruno Haible <bruno@clisp.org>, 2020.  */
+
+#if ENABLE_VALGRIND_SUPPORT
+# include <valgrind/valgrind.h>
+#endif
+#if defined _WIN32 && !defined __CYGWIN__
+# define WIN32_LEAN_AND_MEAN
+# include <windows.h>
+#endif
+#if defined __APPLE__ && defined __MACH__
+# include <libkern/OSCacheControl.h>
+#endif
+#if defined _AIX
+# include <sys/cache.h>
+#endif
+#if defined __sgi
+# include <sys/cachectl.h>
+#endif
+
+/* Clears the instruction cache for addresses
+   start <= address < end.
+   We need this because some CPUs have separate data cache and instruction
+   cache. The freshly built trampoline is visible to the data cache, but
+   maybe not to the instruction cache. This is hairy.  */
+static inline void
+clear_cache (void *start, void *end)
+{
+#if ENABLE_VALGRIND_SUPPORT
+  /* Documentation:
+     <https://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.clientreq>  */
+  VALGRIND_DISCARD_TRANSLATIONS (start, (char *) end - (char *) start);
+#endif
+#if (defined __x86_64__ || defined _M_X64) || (defined __i386 || defined _M_IX86)
+  /* On this architecture, data cache and instruction cache are not separate.
+     Therefore, nothing to do.
+     For details, see
+     <https://stackoverflow.com/questions/10989403/how-is-x86-instruction-cache-synchronized>  */
+
+/* Use the operating system provided function, when available.  */
+#elif defined _WIN32 && !defined __CYGWIN__
+  /* Native Windows.
+     FlushInstructionCache
+     <https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-flushinstructioncache>  */
+  HANDLE process = GetCurrentProcess ();
+  while (!FlushInstructionCache (process, start, (char *) end - (char *) start))
+    ;
+#elif defined __APPLE__ && defined __MACH__
+  /* macOS  */
+  sys_icache_invalidate (start, (char *) end - (char *) start);
+#elif defined _AIX
+  /* AIX.  */
+  _sync_cache_range (start, (char *) end - (char *) start);
+#elif defined __sgi
+  /* IRIX.  */
+  cacheflush (start, (char *) end - (char *) start, ICACHE);
+#elif defined __sun
+  /* Solaris.  */
+  extern void sync_instruction_memory (char *, size_t);
+  sync_instruction_memory (start, (char *) end - (char *) start);
+
+/* No operating system provided function. Dispatch according to the CPU.  */
+#elif (defined __GNUC__ || defined __clang__) && defined __powerpc__
+  /* XXX Is this enough, or do we also need the 'clf' instruction?  */
+  uintptr_t addr = (uintptr_t) start & ~(intptr_t)3;
+  uintptr_t end_addr = (uintptr_t) end;
+  do
+    {
+      asm volatile ("icbi 0,%0; dcbf 0,%0" : : "r" (addr));
+      addr += 4;
+    }
+  while (addr < end_addr);
+  asm volatile ("sync; isync");
+#elif (defined __GNUC__ || defined __clang__) && defined __sparc
+  /* Use inline assembly.  */
+  /* The 'flush' instruction was earlier called 'iflush'.  */
+  uintptr_t addr = (uintptr_t) start & ~(intptr_t)7;
+  uintptr_t end_addr = (uintptr_t) end;
+  do
+    {
+      asm volatile ("flush %0+0" : : "r" (addr));
+      addr += 8;
+    }
+  while (addr < end_addr);
+#elif (defined __GNUC__ || defined __clang__) && defined __m68k__ && defined __linux__
+  /* Use inline assembly to call the 'cacheflush' system call.
+     sys_cacheflush (addr, scope, cache, len)
+                      d1     d2     d3    d4
+   */
+  register uintptr_t addr __asm__ ("%d1") = (uintptr_t) start;
+  register uintptr_t len __asm__ ("%d4") = (uintptr_t) end - addr;
+  __asm__ __volatile__ (
+           "move%.l %#123,%/d0" /* __NR_cacheflush */
+    "\n\t" "move%.l %#1,%/d2"   /* FLUSH_SCOPE_LINE */
+    "\n\t" "move%.l %#3,%/d3"   /* FLUSH_CACHE_BOTH */
+    "\n\t" "trap %#0"
+    :
+    : "d" (addr), "d" (len)
+    : "%d0", "%d2", "%d3"
+    );
+#elif (__GNUC__ + (__GNUC_MINOR__ >= 3) > 4) \
+      || ((__clang_major__ + (__clang_minor__ >= 4) > 3) \
+          && (defined __aarch64__ /* arm64 */ || defined __arm__))
+  /* GCC >= 4.3 has a GCC built-in.
+     <https://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Other-Builtins.html>
+     But it's sometimes not correctly implemented.
+     clang >= 3.4 has it as well, at least on ARM and ARM64.  */
+  /* On ARM, cache flushing can only be done through a system call.
+     GCC implements it for Linux with EABI, through an "swi 0" with code
+     0xf0002.  For other systems, it may be an "swi 0x9f0002",
+     an "swi 0xf00000", or similar.  */
+  /* On ARM64, cache flushing is done through special instructions,
+     and the length of the cache lines must be determined at runtime.
+     See gcc/libgcc/config/aarch64/sync-cache.c.  */
+  __builtin___clear_cache (start, end);
+#elif HAVE___CLEAR_CACHE
+  /* Older versions of GCC have this libgcc function, but only on some
+     platforms.  */
+  extern void __clear_cache (char *, char *);
+  __clear_cache (start, end);
+#else
+# error "Don't know how to implement clear_cache on this platform."
+#endif
+}
diff --git a/m4/valgrind-helper.m4 b/m4/valgrind-helper.m4
new file mode 100644
index 0000000000..b3d70a7ad9
--- /dev/null
+++ b/m4/valgrind-helper.m4
@@ -0,0 +1,22 @@
+# valgrind-helper.m4 serial 1
+dnl Copyright (C) 2023 Free Software Foundation, Inc.
+dnl This file is free software; the Free Software Foundation
+dnl gives unlimited permission to copy and/or distribute it,
+dnl with or without modifications, as long as this notice is preserved.
+
+# Enables support for running the generated binaries under valgrind if
+# - the valgrind header files are installed, and
+# - the user desires so.
+AC_DEFUN_ONCE([gl_VALGRIND_HELPER],
+[
+  AC_ARG_WITH([valgrind],
+    [AS_HELP_STRING([[--with-valgrind]],
+       [enable support for running the binaries under valgrind])],
+    [if test "$withval" != no; then
+       support_valgrind=1
+     else
+       support_valgrind=0
+     fi
+    ])
+  AC_DEFINE_UNQUOTED([ENABLE_VALGRIND_SUPPORT], [$support_valgrind])
+])
diff --git a/modules/jit/cache b/modules/jit/cache
new file mode 100644
index 0000000000..f7af2be314
--- /dev/null
+++ b/modules/jit/cache
@@ -0,0 +1,24 @@
+Description:
+JIT compiler - Flushing the instruction cache.
+
+Files:
+lib/jit/cache.h
+m4/valgrind-helper.m4
+
+Depends-on:
+
+configure.ac:
+gl_VALGRIND_HELPER
+AC_REQUIRE([AC_C_INLINE])
+AC_CHECK_FUNCS([__clear_cache])
+
+Makefile.am:
+
+Include:
+"jit/cache.h"
+
+License:
+LGPLv2+
+
+Maintainer:
+Bruno Haible
-- 
2.34.1

Re: new module 'jit/cache'

[Bruno Haible]

> 	* m4/valgrind-helper.m4: New file.

Oops, that file was incomplete. Fixed like this:


2023-11-13  Bruno Haible  <bruno@clisp.org>

	jit/cache: Fix configure test.
	* m4/valgrind-helper.m4 (gl_VALGRIND_HELPER): Check already at configure
	time whether <valgrind/valgrind.h> exists. Fix AC_DEFINE_UNQUOTED
	invocation.

diff --git a/m4/valgrind-helper.m4 b/m4/valgrind-helper.m4
index b3d70a7ad9..99c31030b9 100644
--- a/m4/valgrind-helper.m4
+++ b/m4/valgrind-helper.m4
@@ -1,4 +1,4 @@
-# valgrind-helper.m4 serial 1
+# valgrind-helper.m4 serial 2
 dnl Copyright (C) 2023 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -18,5 +18,13 @@ AC_DEFUN_ONCE([gl_VALGRIND_HELPER]
        support_valgrind=0
      fi
     ])
-  AC_DEFINE_UNQUOTED([ENABLE_VALGRIND_SUPPORT], [$support_valgrind])
+  if test $support_valgrind = 1; then
+    AC_CHECK_HEADERS([valgrind/valgrind.h])
+    if test $ac_cv_header_valgrind_valgrind_h != yes; then
+      AC_MSG_ERROR([cannot enable valgrind support: <valgrind/valgrind.h> not found])
+    fi
+  fi
+  AC_DEFINE_UNQUOTED([ENABLE_VALGRIND_SUPPORT], [$support_valgrind],
+    [Define to 1 to include support for running the binaries under valgrind,
+     or to 0 otherwise.])
 ])

Re: test environments

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

Hi Bruno,

Thanks for making your module available.  I have acquired a Raspberry Pi
with an ARMv8, so as soon as my time permits, I should be able to do some
testing.

Marc

Am Mo., 13. Nov. 2023 um 00:10 Uhr schrieb Bruno Haible <bruno@clisp.org>:

> Marc Nieper-Wißkirchen wrote:
> > I only have access to x86_64 systems, for which `clear_cache ()' can be a
> > no-op.  Emulators aren't of much help because they usually do not
> implement
> > the need for cache invalidation faithfully.  We would need the help of
> > someone with, say, an Aarch64 system.
>
> I've added info about how to get access to test environments here:
>
> https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=blob;f=platforms/test-environments.txt
>
> https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=tree;f=platforms/environments
>
> In particular, the compile farm has 4 machines with aarch64 CPU.
> Maybe you also have an Android phone with aarch64 CPU on it (and
> can install Termux in 64-bit mode on it)?
>
> It is correct that emulators sometimes don't implement the need for
> cache invalidation correctly; I observed this for mips too. But QEMU
> is quite good nowadays; it's better than nothing.
>
> Bruno
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2225 bytes --]

Re: test environments

[Bruno Haible]

Marc Nieper-Wißkirchen wrote:
> I have acquired a Raspberry Pi with an ARMv8

Good point. I added a bit more info:
https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=commitdiff;h=09212bac9fc0e41fe11826d9d89965d8e54d4c98

Bruno

Re: test environments

[Sam James]

Bruno Haible <bruno@clisp.org> writes:

> Marc Nieper-Wißkirchen wrote:
>> I only have access to x86_64 systems, for which `clear_cache ()' can be a
>> no-op.  Emulators aren't of much help because they usually do not implement
>> the need for cache invalidation faithfully.  We would need the help of
>> someone with, say, an Aarch64 system.
>
> I've added info about how to get access to test environments here:
>   https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=blob;f=platforms/test-environments.txt
>   https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=tree;f=platforms/environments

Thanks for doing that Bruno. Please also see
https://static.matoro.tk/isa-sandbox-faq.html - maybe give it a mention,
it's run by a great contributor, matoro, who is quite dedicated (CC'd).

>
> In particular, the compile farm has 4 machines with aarch64 CPU.
> Maybe you also have an Android phone with aarch64 CPU on it (and
> can install Termux in 64-bit mode on it)?

Termux is definitely worth people trying, although in my experience,
it's rather different from a usual arm64 environment (partly I think
because of seccomp filtering and such).

>
> It is correct that emulators sometimes don't implement the need for
> cache invalidation correctly; I observed this for mips too. But QEMU
> is quite good nowadays; it's better than nothing.
>

Yes, and people should keep in mind that `qemu-user` is *extremely*
convenient, avoiding the need to do a full install of a distribution
with partitioning and such...

One can just chroot in to a e.g. Gentoo stage3, or a Debian
debootstrap'd directory.

> Bruno

thanks,
sam

Re: test environments

[Bruno Haible]

Sam James wrote:
> Please also see
> https://static.matoro.tk/isa-sandbox-faq.html - maybe give it a mention,
> it's run by a great contributor, matoro, who is quite dedicated (CC'd).

That looks like a wonderful resource
  - for hardware dependent things (like the cache behaviour),
  - for determining whether a behaviour is a QEMU bug or not.

Matoro, what's the OS on these machines? Are they all running glibc?

> Yes, and people should keep in mind that `qemu-user` is *extremely*
> convenient

Yes, qemu in "user mode" is very convenient. But, as I wrote, it has its
limitations: when it comes to signals, ioctl(), iconv(), floating-point
stuff, or similar.

Bruno

Re: test environments

[matoro via Gnulib discussion list]

On 2023-11-15 06:15, Bruno Haible wrote:
> Sam James wrote:
>> Please also see
>> https://static.matoro.tk/isa-sandbox-faq.html - maybe give it a mention,
>> it's run by a great contributor, matoro, who is quite dedicated (CC'd).
> 
> That looks like a wonderful resource
>   - for hardware dependent things (like the cache behaviour),
>   - for determining whether a behaviour is a QEMU bug or not.
> 
> Matoro, what's the OS on these machines? Are they all running glibc?

Hi Bruno!  These all run Gentoo unstable, with relevant glibc (currently 
2.38).

Feel free to pip in on IRC or shoot me an email to get an account.

>> Yes, and people should keep in mind that `qemu-user` is *extremely*
>> convenient
> 
> Yes, qemu in "user mode" is very convenient. But, as I wrote, it has its
> limitations: when it comes to signals, ioctl(), iconv(), floating-point
> stuff, or similar.
> 
> Bruno

Re: test environments

[Bruno Haible]

Hi Matoro,

> These all run Gentoo unstable, with relevant glibc (currently 2.38).

Thanks. I've added the info at
https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=blob;f=platforms/test-environments.txt

> Feel free to pip in on IRC or shoot me an email to get an account.

Thanks, I'll do that. The glibc people have requested hardware testing
on Linux/alpha and Linux/hppa for two patches of mine [1], and it will also
be useful for testing the 'jit/cache' module when Marc has written a unit
test for it.

Bruno

[1] https://sourceware.org/pipermail/libc-alpha/2023-November/152466.html

Re: new module 'jit/cache'

[Marc Nieper-Wißkirchen]

[-- Attachment #1.1: Type: text/plain, Size: 1884 bytes --]

Hello Bruno,

Here is my attempt at a simple unit test for your new cache module.

I have tested it on an x86 box (where the instruction cache is always in
sync) and on an Armv8 Raspberry, both running GNU/Linux.  Commenting out
the call to `clear_cache' shows that `clear_cache' is not a NOP on Arm and
that the test is actually doing a non-trivial test.

Best,

Marc

Am Mo., 13. Nov. 2023 um 14:33 Uhr schrieb Bruno Haible <bruno@clisp.org>:

> >       * m4/valgrind-helper.m4: New file.
>
> Oops, that file was incomplete. Fixed like this:
>
>
> 2023-11-13  Bruno Haible  <bruno@clisp.org>
>
>         jit/cache: Fix configure test.
>         * m4/valgrind-helper.m4 (gl_VALGRIND_HELPER): Check already at
> configure
>         time whether <valgrind/valgrind.h> exists. Fix AC_DEFINE_UNQUOTED
>         invocation.
>
> diff --git a/m4/valgrind-helper.m4 b/m4/valgrind-helper.m4
> index b3d70a7ad9..99c31030b9 100644
> --- a/m4/valgrind-helper.m4
> +++ b/m4/valgrind-helper.m4
> @@ -1,4 +1,4 @@
> -# valgrind-helper.m4 serial 1
> +# valgrind-helper.m4 serial 2
>  dnl Copyright (C) 2023 Free Software Foundation, Inc.
>  dnl This file is free software; the Free Software Foundation
>  dnl gives unlimited permission to copy and/or distribute it,
> @@ -18,5 +18,13 @@ AC_DEFUN_ONCE([gl_VALGRIND_HELPER]
>         support_valgrind=0
>       fi
>      ])
> -  AC_DEFINE_UNQUOTED([ENABLE_VALGRIND_SUPPORT], [$support_valgrind])
> +  if test $support_valgrind = 1; then
> +    AC_CHECK_HEADERS([valgrind/valgrind.h])
> +    if test $ac_cv_header_valgrind_valgrind_h != yes; then
> +      AC_MSG_ERROR([cannot enable valgrind support: <valgrind/valgrind.h>
> not found])
> +    fi
> +  fi
> +  AC_DEFINE_UNQUOTED([ENABLE_VALGRIND_SUPPORT], [$support_valgrind],
> +    [Define to 1 to include support for running the binaries under
> valgrind,
> +     or to 0 otherwise.])
>  ])
>
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 2996 bytes --]

[-- Attachment #2: 0001-jit-cache-tests-New-module.patch --]
[-- Type: text/x-patch, Size: 4503 bytes --]

From 335cc8f54e4510d4a9025a401cc67a7d32ce1f56 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marc=20Nieper-Wi=C3=9Fkirchen?= <marc@nieper-wisskirchen.de>
Date: Sat, 25 Nov 2023 18:14:55 +0100
Subject: [PATCH] jit/cache-tests: New module.

* m4/valgrind-helper.m4: Unconditionally set support_valgrind to
fix configure error.
* modules/jit/cache-tests: New file.  Mark the test as unportable
for now.
* tests/jit/test-cache.c: New file.
---
 ChangeLog               |  9 +++++
 m4/valgrind-helper.m4   |  3 +-
 modules/jit/cache-tests | 20 +++++++++++
 tests/jit/test-cache.c  | 77 +++++++++++++++++++++++++++++++++++++++++
 4 files changed, 108 insertions(+), 1 deletion(-)
 create mode 100644 modules/jit/cache-tests
 create mode 100644 tests/jit/test-cache.c

diff --git a/ChangeLog b/ChangeLog
index 1834acd9da..89419032b3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2023-11-25  Marc Nieper-Wißkirchen  <marc@nieper-wisskirchen.de>
+
+	jit/cache-tests: New module.
+	* m4/valgrind-helper.m4: Unconditionally set support_valgrind to
+	fix configure error.
+	* modules/jit/cache-tests: New file.  Mark the test as unportable
+	for now.
+	* tests/jit/test-cache.c: New file.
+
 2023-11-24  Bruno Haible  <bruno@clisp.org>
 
 	floorf, ceilf tests: Strengthen against compiler optimizations.
diff --git a/m4/valgrind-helper.m4 b/m4/valgrind-helper.m4
index 99c31030b9..90637e6745 100644
--- a/m4/valgrind-helper.m4
+++ b/m4/valgrind-helper.m4
@@ -17,7 +17,8 @@ AC_DEFUN_ONCE([gl_VALGRIND_HELPER],
      else
        support_valgrind=0
      fi
-    ])
+    ],
+    [support_valgrind=0])
   if test $support_valgrind = 1; then
     AC_CHECK_HEADERS([valgrind/valgrind.h])
     if test $ac_cv_header_valgrind_valgrind_h != yes; then
diff --git a/modules/jit/cache-tests b/modules/jit/cache-tests
new file mode 100644
index 0000000000..eff828890d
--- /dev/null
+++ b/modules/jit/cache-tests
@@ -0,0 +1,20 @@
+Files:
+tests/jit/test-cache.c
+tests/macros.h
+
+Status:
+unportable-test
+
+Depends-on:
+getpagesize
+pagealign_alloc
+stdint
+
+configure.ac:
+AC_CHECK_HEADERS_ONCE([sys/mman.h])
+AC_CHECK_FUNCS_ONCE([mprotect])
+
+Makefile.am:
+TESTS += test-cache
+check_PROGRAMS += test-cache
+test_cache_SOURCES = jit/test-cache.c
diff --git a/tests/jit/test-cache.c b/tests/jit/test-cache.c
new file mode 100644
index 0000000000..47c81a8b1e
--- /dev/null
+++ b/tests/jit/test-cache.c
@@ -0,0 +1,77 @@
+/* Test clear_cache.
+
+   Copyright 2023 Free Software Foundation, Inc.
+
+   This program is free software: you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation, either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <https://www.gnu.org/licenses/>.  */
+
+#include <config.h>
+
+#include <jit/cache.h>
+
+#include <pagealign_alloc.h>
+#include <string.h>
+#include <unistd.h>
+
+#if HAVE_SYS_MMAN_H && HAVE_MPROTECT
+# include <sys/mman.h>
+#endif
+
+#include "macros.h"
+
+/* This test assumes that the code generated by the compiler for the
+   procedures `return1' and `return2' is position independent.  It
+   also assumes that function pointers are compatible with data
+   pointers and that these are bit-compatible to integers.  */
+
+static int
+return1 (void)
+{
+  return 1;
+}
+
+static int
+return2 (void)
+{
+  return 2;
+}
+
+int
+main ()
+{
+#if !(HAVE_SYS_MMAN_H && HAVE_SYS_MMAN_H)
+  return 77;
+#endif
+
+  int const pagesize = getpagesize ();
+  unsigned char *start = pagealign_xalloc (pagesize);
+  unsigned char *end = start + pagesize;
+
+  /* We have to call `mprotect' before the tests because on some
+     platforms `mprotect' invalidates the caches.  */
+  mprotect (start, end - start, PROT_READ | PROT_WRITE | PROT_EXEC);
+
+  int (*f) (void) = (void *) start;
+
+  /* We assume that the code is not longer than 64 bytes and that we
+     can access the full 64 bytes for reading.  */
+  memcpy (start, return1, 64);
+  clear_cache (start, end);
+  ASSERT (f () == 1);
+
+  memcpy (start, return2, 64);
+  clear_cache (start, end);
+  ASSERT (f () == 2);
+
+  return 0;
+}
-- 
2.40.1

Re: new module 'jit/cache'

[Bruno Haible]

Hello Marc,

> Here is my attempt at a simple unit test for your new cache module.
> 
> I have tested it on an x86 box (where the instruction cache is always in
> sync) and on an Armv8 Raspberry, both running GNU/Linux.  Commenting out
> the call to `clear_cache' shows that `clear_cache' is not a NOP on Arm and
> that the test is actually doing a non-trivial test.

Very nice! It is simpler than what I had expected (no per-CPU #ifdefs so far).

I've committed your patch (as two separate patches).

I will test it on various platforms.

For the moment, I expect
  - a SIGSEGV on powerpc*-aix, powerpc64-linux, ia64, hppa, and hppa64
    due to the structure of function pointers, see
    https://git.savannah.gnu.org/gitweb/?p=libffcall.git;a=blob;f=porting-tools/abis/function-pointer.txt
  - a link error on native Windows, due to the use of mprotect() outside
    #ifdefs.

But we'll see...

Bruno

Re: new module 'jit/cache'

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

Am Sa., 25. Nov. 2023 um 21:19 Uhr schrieb Bruno Haible <bruno@clisp.org>:

> Hello Marc,
>
> > Here is my attempt at a simple unit test for your new cache module.
> >
> > I have tested it on an x86 box (where the instruction cache is always in
> > sync) and on an Armv8 Raspberry, both running GNU/Linux.  Commenting out
> > the call to `clear_cache' shows that `clear_cache' is not a NOP on Arm
> and
> > that the test is actually doing a non-trivial test.
>
> Very nice! It is simpler than what I had expected (no per-CPU #ifdefs so
> far).
>

I am sure they will come as soon as it is tested on more platforms than
just GNU/Linux with x86_64 and aarch64.

The alternative would be to pull in the whole GNU lightning...

I've committed your patch (as two separate patches).
>
> I will test it on various platforms.
>
> For the moment, I expect
>   - a SIGSEGV on powerpc*-aix, powerpc64-linux, ia64, hppa, and hppa64
>     due to the structure of function pointers, see
>
> https://git.savannah.gnu.org/gitweb/?p=libffcall.git;a=blob;f=porting-tools/abis/function-pointer.txt


Thank you; I will try to incorporate this info into my test.

  - a link error on native Windows, due to the use of mprotect() outside
>     #ifdefs.
>

Of course! I am going to fix this.

[-- Attachment #2: Type: text/html, Size: 2603 bytes --]

Re: new module 'jit/cache'

[Marc Nieper-Wißkirchen]

[-- Attachment #1.1: Type: text/plain, Size: 657 bytes --]

Am Mo., 27. Nov. 2023 um 17:27 Uhr schrieb Marc Nieper-Wißkirchen <
marc.nieper+gnu@gmail.com>:

[...]



> For the moment, I expect
>>   - a SIGSEGV on powerpc*-aix, powerpc64-linux, ia64, hppa, and hppa64
>>     due to the structure of function pointers, see
>>
>> https://git.savannah.gnu.org/gitweb/?p=libffcall.git;a=blob;f=porting-tools/abis/function-pointer.txt
>
>
> Thank you; I will try to incorporate this info into my test.
>

I have attached a patch file to review my ideas.  The code hasn't been
checked on the platforms actually touched by the patch.  It has not been
committed yet (and lacks a ChangeLog entry).

Marc

[-- Attachment #1.2: Type: text/html, Size: 1695 bytes --]

[-- Attachment #2: jit-cache.patch --]
[-- Type: application/octet-stream, Size: 1898 bytes --]

diff --git a/modules/jit/cache-tests b/modules/jit/cache-tests
index eff828890d..6a713f8bb9 100644
--- a/modules/jit/cache-tests
+++ b/modules/jit/cache-tests
@@ -7,6 +7,7 @@ unportable-test
 
 Depends-on:
 getpagesize
+host-cpu-c-abi
 pagealign_alloc
 stdint
 
diff --git a/tests/jit/test-cache.c b/tests/jit/test-cache.c
index 3158d02117..2919605e33 100644
--- a/tests/jit/test-cache.c
+++ b/tests/jit/test-cache.c
@@ -29,10 +29,55 @@
 
 #include "macros.h"
 
+/*  On most platforms, function pointers are just a pointer to the
+    code, i.e. to the first instruction to be executed.  This,
+    however, is not universally true, see:
+    https://git.savannah.gnu.org/gitweb/?p=libffcall.git;a=blob;f=porting-tools/abis/function-pointer.txt.  */
+
+#define CODE(fn) (((struct func *) (fn))->code_address)
+#if ((defined __powerpc__ || defined __powerpc64__) && defined _AIX) || (defined __powerpc64__ && defined __linux__)
+struct func
+{
+  void *code_address;
+  void *toc_pointer;
+  void *static_chain;
+};
+#elif defined __ia64__
+struct func
+{
+  void *code_address;
+  void *global_pointer;
+};
+#elif defined __ia64_ilp32__
+struct func
+{
+  void *code_address;
+  void *unused1;
+  void *global_pointer;
+  void *unused2;
+};
+#elif __hppa__
+struct func
+{
+  void *code_address;
+  void *pic_base;
+};
+#elif __hppa64__
+struct func
+{
+  void *some_other_code_address;
+  void *some_other_pic_base;
+  void *code_address;
+  void *pic_base;
+};
+#else
+# undef CODE
+# define CODE(fn) ((void *) (fn))
+#endif
+
 /* This test assumes that the code generated by the compiler for the
    procedures `return1' and `return2' is position independent.  It
-   also assumes that function pointers are compatible with data
-   pointers and that these are bit-compatible to integers.  */
+   also assumes that data pointers are bit-compatible to integers.  */
 
 static int
 return1 (void)

Re: new module 'jit/cache'

[Marc Nieper-Wißkirchen]

[-- Attachment #1.1: Type: text/plain, Size: 918 bytes --]

I forgot to actually make use of the patched part in the test case; here is
the full patch.  Please excuse the mess.



Am Mo., 27. Nov. 2023 um 18:36 Uhr schrieb Marc Nieper-Wißkirchen <
marc.nieper+gnu@gmail.com>:

> Am Mo., 27. Nov. 2023 um 17:27 Uhr schrieb Marc Nieper-Wißkirchen <
> marc.nieper+gnu@gmail.com>:
>
> [...]
>
>
>
>> For the moment, I expect
>>>   - a SIGSEGV on powerpc*-aix, powerpc64-linux, ia64, hppa, and hppa64
>>>     due to the structure of function pointers, see
>>>
>>> https://git.savannah.gnu.org/gitweb/?p=libffcall.git;a=blob;f=porting-tools/abis/function-pointer.txt
>>
>>
>> Thank you; I will try to incorporate this info into my test.
>>
>
> I have attached a patch file to review my ideas.  The code hasn't been
> checked on the platforms actually touched by the patch.  It has not been
> committed yet (and lacks a ChangeLog entry).
>
> Marc
>
>

[-- Attachment #1.2: Type: text/html, Size: 2412 bytes --]

[-- Attachment #2: jit-cache.patch --]
[-- Type: application/octet-stream, Size: 2269 bytes --]

diff --git a/modules/jit/cache-tests b/modules/jit/cache-tests
index eff828890d..6a713f8bb9 100644
--- a/modules/jit/cache-tests
+++ b/modules/jit/cache-tests
@@ -7,6 +7,7 @@ unportable-test
 
 Depends-on:
 getpagesize
+host-cpu-c-abi
 pagealign_alloc
 stdint
 
diff --git a/tests/jit/test-cache.c b/tests/jit/test-cache.c
index 3158d02117..145b63e0e8 100644
--- a/tests/jit/test-cache.c
+++ b/tests/jit/test-cache.c
@@ -29,10 +29,55 @@
 
 #include "macros.h"
 
+/*  On most platforms, function pointers are just a pointer to the
+    code, i.e. to the first instruction to be executed.  This,
+    however, is not universally true, see:
+    https://git.savannah.gnu.org/gitweb/?p=libffcall.git;a=blob;f=porting-tools/abis/function-pointer.txt.  */
+
+#define CODE(fn) (((struct func *) (fn))->code_address)
+#if ((defined __powerpc__ || defined __powerpc64__) && defined _AIX) || (defined __powerpc64__ && defined __linux__)
+struct func
+{
+  void *code_address;
+  void *toc_pointer;
+  void *static_chain;
+};
+#elif defined __ia64__
+struct func
+{
+  void *code_address;
+  void *global_pointer;
+};
+#elif defined __ia64_ilp32__
+struct func
+{
+  void *code_address;
+  void *unused1;
+  void *global_pointer;
+  void *unused2;
+};
+#elif __hppa__
+struct func
+{
+  void *code_address;
+  void *pic_base;
+};
+#elif __hppa64__
+struct func
+{
+  void *some_other_code_address;
+  void *some_other_pic_base;
+  void *code_address;
+  void *pic_base;
+};
+#else
+# undef CODE
+# define CODE(fn) ((*(void **) (&fn)))
+#endif
+
 /* This test assumes that the code generated by the compiler for the
    procedures `return1' and `return2' is position independent.  It
-   also assumes that function pointers are compatible with data
-   pointers and that these are bit-compatible to integers.  */
+   also assumes that data pointers are bit-compatible to integers.  */
 
 static int
 return1 (void)
@@ -60,7 +105,8 @@ main ()
      platforms `mprotect' invalidates the caches.  */
   mprotect (start, end - start, PROT_READ | PROT_WRITE | PROT_EXEC);
 
-  int (*f) (void) = (void *) start;
+  int (*f) (void) = return1;
+  CODE (f) = start;
 
   /* We assume that the code is not longer than 64 bytes and that we
      can access the full 64 bytes for reading.  */

QEMU-based test environments

[Bruno Haible]

On 2023-11-12 I wrote:
> I've added info about how to get access to test environments here:
>   https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=blob;f=platforms/test-environments.txt
>   https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=tree;f=platforms/environments

Now, I have added more detailed instructions regarding QEMU-based test
environments:
  - A step-by-step procedure for how to create a QEMU-based environment, with
    as little trial-and-error as possible.
  - 38 examples of this procedure, for platforms ranging from Linux/alpha
    to NetBSD/sparc64.

The writeups are here:
  https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=tree;f=platforms/environments

Thanks to René Rebe from the T2-SDE distribution for teaching me about the
Linux kernel option 'console=ttyS0', that is sometimes essential.

Bruno

Re: new module 'jit/cache'

[Bruno Haible]

Hi Marc,

> I forgot to actually make use of the patched part in the test case; here is
> the full patch.  Please excuse the mess.

Looks good to me. As I want to start testing it, I committed the patch for you.

Bruno

Re: new module 'jit/cache'

[Bruno Haible]

My (preliminary) test results:

The test passes on x86_64, m68k, alpha, s390, s390x, riscv64, loongarch64.

It fails on some platforms with i386, mips, sparc, arm, arm64

It fails on all platforms with powerpc*, ia64.

Bruno

Re: new module 'jit/cache'

[Marc Nieper-Wißkirchen]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

Do you have detailed test results/logs?

Thanks,

Marc

Am Di., 19. Dez. 2023 um 23:13 Uhr schrieb Bruno Haible <bruno@clisp.org>:

> My (preliminary) test results:
>
> The test passes on x86_64, m68k, alpha, s390, s390x, riscv64, loongarch64.
>
> It fails on some platforms with i386, mips, sparc, arm, arm64
>
> It fails on all platforms with powerpc*, ia64.
>
> Bruno
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1040 bytes --]

Re: Provide a module for `clear_cache'

[Bruno Haible]

Marc Nieper-Wißkirchen wrote on 2023-11-06:
> Emulators aren't of much help because they usually do not implement
> the need for cache invalidation faithfully.

Indeed, you were right. In my testing on various platforms:
  * I haven't seen the assertion
      ASSERT (f () == 2);
    fail on any QEMU-based VM.
  * I could confirm your statement regarding MIPS, many years ago.
  * On
       Linux/hppa
       Linux/powerpc
       Linux/powerpc64
       Linux/powerpc64le
    I now saw the test succeed in a QEMU-based VM but fail on real hardware.

Bruno

more QEMU-based test environments

[Bruno Haible]

On 2023-12-17 I wrote:
> The writeups are here:
>   https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=tree;f=platforms/environments

Now I've added some more environment descriptions:
  hppa - NetBSD
  hppa - OpenBSD
  powerpc - NetBSD
  powerpc64 - FreeBSD
  ppc64le - FreeBSD

The two hppa environments are not 100% reliable, but reasonably usable
nevertheless.

Bruno

Re: more QEMU-based test environments

[Bruno Haible]

> > The writeups are here:
> >   https://git.savannah.gnu.org/gitweb/?p=gnulib/maint-tools.git;a=tree;f=platforms/environments

Some more environment descriptions:
  arm64 - NetBSD
  arm64 - OpenBSD
  sparc64 - OpenBSD

Bruno