[2/5] nolibc: add support for s390
Commit Message
Use arch-x86_64 as a template. Not really different, but
we have our own mmap syscall which takes a structure instead
of discrete arguments.
Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
---
tools/include/nolibc/arch-s390.h | 213 +++++++++++++++++++++++++++++++
tools/include/nolibc/arch.h | 2 +
tools/include/nolibc/sys.h | 2 +
3 files changed, 217 insertions(+)
create mode 100644 tools/include/nolibc/arch-s390.h
Comments
On Fri, Dec 09, 2022 at 03:19:36PM +0100, Sven Schnelle wrote:
> Use arch-x86_64 as a template. Not really different, but
> we have our own mmap syscall which takes a structure instead
> of discrete arguments.
I'm fine with placing the mmap syscall inside the arch-s390 file, though
it differs from what's done for other syscalls. But I admit that mmap is
one of these syscalls that differ between various archs and that it's not
shocking to leave it per-arch.
However you're having an issue here:
> diff --git a/tools/include/nolibc/arch-s390.h b/tools/include/nolibc/arch-s390.h
> new file mode 100644
> index 000000000000..34b744e2f7d6
> --- /dev/null
> +++ b/tools/include/nolibc/arch-s390.h
^^^^^^^^^
vs:
> diff --git a/tools/include/nolibc/arch.h b/tools/include/nolibc/arch.h
> index 4c6992321b0d..fcded65b98d7 100644
> --- a/tools/include/nolibc/arch.h
> +++ b/tools/include/nolibc/arch.h
> @@ -27,6 +27,8 @@
> #include "arch-mips.h"
> #elif defined(__riscv)
> #include "arch-riscv.h"
> +#elif defined(__s390x__)
> +#include "arch-s390x.h"
^^^^^^^^^^
As you see the file is not the same so if you build by including nolibc.h
directly it will not work. The difference between s390 and s390x has never
been very clear to me, so I can't easily suggest which name is the most
suitable, but you'll definitely have to choose one :-) If it's just a
matter of dropping that trailing 'x' there, I think we can fix your patch
here without re-submitting, let us know.
Once this one is fixed, I'm fine with this:
Acked-by: Willy Tarreau <w@1wt.eu>
Willy
Willy Tarreau <w@1wt.eu> writes:
> On Fri, Dec 09, 2022 at 03:19:36PM +0100, Sven Schnelle wrote:
>> Use arch-x86_64 as a template. Not really different, but
>> we have our own mmap syscall which takes a structure instead
>> of discrete arguments.
>
> I'm fine with placing the mmap syscall inside the arch-s390 file, though
> it differs from what's done for other syscalls. But I admit that mmap is
> one of these syscalls that differ between various archs and that it's not
> shocking to leave it per-arch.
>
> However you're having an issue here:
>
>> diff --git a/tools/include/nolibc/arch-s390.h b/tools/include/nolibc/arch-s390.h
>> new file mode 100644
>> index 000000000000..34b744e2f7d6
>> --- /dev/null
>> +++ b/tools/include/nolibc/arch-s390.h
> ^^^^^^^^^
> vs:
>
>> diff --git a/tools/include/nolibc/arch.h b/tools/include/nolibc/arch.h
>> index 4c6992321b0d..fcded65b98d7 100644
>> --- a/tools/include/nolibc/arch.h
>> +++ b/tools/include/nolibc/arch.h
>> @@ -27,6 +27,8 @@
>> #include "arch-mips.h"
>> #elif defined(__riscv)
>> #include "arch-riscv.h"
>> +#elif defined(__s390x__)
>> +#include "arch-s390x.h"
> ^^^^^^^^^^
>
> As you see the file is not the same so if you build by including nolibc.h
> directly it will not work. The difference between s390 and s390x has never
> been very clear to me, so I can't easily suggest which name is the most
> suitable, but you'll definitely have to choose one :-) If it's just a
> matter of dropping that trailing 'x' there, I think we can fix your patch
> here without re-submitting, let us know.
Whoops. One of my colleagues suggested that i should name the file
arch-390x.h. Reason for this is that the architecture name "s390"
describes the 31bit (compat) architecture mode in userspace, and "s390x"
the 64 bit mode. To make it a bit more complicated, the architecture in
the kernel is named "s390". That's because in the beginning the kernel
could run in 31bit or 64 bit mode, and there can be only one
architecture name. When support for running 31bit kernels was removed
years ago, the architecture name s390 was kept because renaming the
architecture would have been quite some fun. So in short:
Kernel s390 == 64 bit only
Userspace s390 == 31 bit
Userspace s390x == 64 bit
So i tried renaming the header file, noted that the Makefile just uses:
nolibc_arch := $(patsubst arm64,aarch64,$(ARCH))
arch_file := arch-$(nolibc_arch).h
which would then need special handling. Obviously i failed to revert the
change completely during rebase.
So it should be:
>> +#elif defined(__s390x__)
>> +#include "arch-s390.h"
I'm fine with both - either you fixing it up or me sending a v2.
Thanks!
Sven
On Sat, Dec 10, 2022 at 10:34:08AM +0100, Sven Schnelle wrote:
> Whoops. One of my colleagues suggested that i should name the file
> arch-390x.h. Reason for this is that the architecture name "s390"
> describes the 31bit (compat) architecture mode in userspace, and "s390x"
> the 64 bit mode. To make it a bit more complicated, the architecture in
> the kernel is named "s390". That's because in the beginning the kernel
> could run in 31bit or 64 bit mode, and there can be only one
> architecture name. When support for running 31bit kernels was removed
> years ago, the architecture name s390 was kept because renaming the
> architecture would have been quite some fun. So in short:
>
> Kernel s390 == 64 bit only
> Userspace s390 == 31 bit
> Userspace s390x == 64 bit
OK, that might be why it's always a bit confusing to me :-)
> So i tried renaming the header file, noted that the Makefile just uses:
>
> nolibc_arch := $(patsubst arm64,aarch64,$(ARCH))
> arch_file := arch-$(nolibc_arch).h
>
> which would then need special handling. Obviously i failed to revert the
> change completely during rebase.
>
> So it should be:
>
> >> +#elif defined(__s390x__)
> >> +#include "arch-s390.h"
>
> I'm fine with both - either you fixing it up or me sending a v2.
As you like. If you prefer to rename the file to s390x as your colleague
suggested, I'll then ask you to send a v2. Otherwise either Paul or I can
drop that 'x' in the #include.
Thanks,
Willy
Willy Tarreau <w@1wt.eu> writes:
> On Sat, Dec 10, 2022 at 10:34:08AM +0100, Sven Schnelle wrote:
>> So it should be:
>>
>> >> +#elif defined(__s390x__)
>> >> +#include "arch-s390.h"
>>
>> I'm fine with both - either you fixing it up or me sending a v2.
>
> As you like. If you prefer to rename the file to s390x as your colleague
> suggested, I'll then ask you to send a v2. Otherwise either Paul or I can
> drop that 'x' in the #include.
Just drop the 'x'. Thanks! :)
On Sat, Dec 10, 2022 at 10:39:43AM +0100, Sven Schnelle wrote:
> Willy Tarreau <w@1wt.eu> writes:
>
> > On Sat, Dec 10, 2022 at 10:34:08AM +0100, Sven Schnelle wrote:
> >> So it should be:
> >>
> >> >> +#elif defined(__s390x__)
> >> >> +#include "arch-s390.h"
> >>
> >> I'm fine with both - either you fixing it up or me sending a v2.
> >
> > As you like. If you prefer to rename the file to s390x as your colleague
> > suggested, I'll then ask you to send a v2. Otherwise either Paul or I can
> > drop that 'x' in the #include.
>
> Just drop the 'x'. Thanks! :)
OK will do, thank you!
Wlily
On Sat, Dec 10, 2022 at 10:44:52AM +0100, Willy Tarreau wrote:
> On Sat, Dec 10, 2022 at 10:39:43AM +0100, Sven Schnelle wrote:
> > Willy Tarreau <w@1wt.eu> writes:
> >
> > > On Sat, Dec 10, 2022 at 10:34:08AM +0100, Sven Schnelle wrote:
> > >> So it should be:
> > >>
> > >> >> +#elif defined(__s390x__)
> > >> >> +#include "arch-s390.h"
> > >>
> > >> I'm fine with both - either you fixing it up or me sending a v2.
> > >
> > > As you like. If you prefer to rename the file to s390x as your colleague
> > > suggested, I'll then ask you to send a v2. Otherwise either Paul or I can
> > > drop that 'x' in the #include.
> >
> > Just drop the 'x'. Thanks! :)
>
> OK will do, thank you!
And I have queued this series with Willy's acks on the first three and
the "x" removed from the '#include "arch-s390x.h"'. This is on the -rcu
tree's "dev" branch.
But please double-check to make sure that I removed the correct "x"
and that there are not others that I missed!
Thanx, Paul
On Sat, Dec 10, 2022 at 09:57:14AM -0800, Paul E. McKenney wrote:
> On Sat, Dec 10, 2022 at 10:44:52AM +0100, Willy Tarreau wrote:
> > On Sat, Dec 10, 2022 at 10:39:43AM +0100, Sven Schnelle wrote:
> > > Willy Tarreau <w@1wt.eu> writes:
> > >
> > > > On Sat, Dec 10, 2022 at 10:34:08AM +0100, Sven Schnelle wrote:
> > > >> So it should be:
> > > >>
> > > >> >> +#elif defined(__s390x__)
> > > >> >> +#include "arch-s390.h"
> > > >>
> > > >> I'm fine with both - either you fixing it up or me sending a v2.
> > > >
> > > > As you like. If you prefer to rename the file to s390x as your colleague
> > > > suggested, I'll then ask you to send a v2. Otherwise either Paul or I can
> > > > drop that 'x' in the #include.
> > >
> > > Just drop the 'x'. Thanks! :)
> >
> > OK will do, thank you!
>
> And I have queued this series with Willy's acks on the first three and
> the "x" removed from the '#include "arch-s390x.h"'. This is on the -rcu
> tree's "dev" branch.
>
> But please double-check to make sure that I removed the correct "x"
> and that there are not others that I missed!
Just checked, looks good to me, many thanks Paul!
Willy
On Sat, Dec 10, 2022 at 11:05:04PM +0100, Willy Tarreau wrote:
> On Sat, Dec 10, 2022 at 09:57:14AM -0800, Paul E. McKenney wrote:
> > On Sat, Dec 10, 2022 at 10:44:52AM +0100, Willy Tarreau wrote:
> > > On Sat, Dec 10, 2022 at 10:39:43AM +0100, Sven Schnelle wrote:
> > > > Willy Tarreau <w@1wt.eu> writes:
> > > >
> > > > > On Sat, Dec 10, 2022 at 10:34:08AM +0100, Sven Schnelle wrote:
> > > > >> So it should be:
> > > > >>
> > > > >> >> +#elif defined(__s390x__)
> > > > >> >> +#include "arch-s390.h"
> > > > >>
> > > > >> I'm fine with both - either you fixing it up or me sending a v2.
> > > > >
> > > > > As you like. If you prefer to rename the file to s390x as your colleague
> > > > > suggested, I'll then ask you to send a v2. Otherwise either Paul or I can
> > > > > drop that 'x' in the #include.
> > > >
> > > > Just drop the 'x'. Thanks! :)
> > >
> > > OK will do, thank you!
> >
> > And I have queued this series with Willy's acks on the first three and
> > the "x" removed from the '#include "arch-s390x.h"'. This is on the -rcu
> > tree's "dev" branch.
> >
> > But please double-check to make sure that I removed the correct "x"
> > and that there are not others that I missed!
>
> Just checked, looks good to me, many thanks Paul!
Whew! And thank you for checking!
Thanx, Paul
Hi Sven,
On Fri, Dec 09, 2022 at 03:19:36PM +0100, Sven Schnelle wrote:
> Use arch-x86_64 as a template. Not really different, but
> we have our own mmap syscall which takes a structure instead
> of discrete arguments.
(...)
This evening I downloaded an s390 toolchain from kernel.org's nolibc
toolchains and expected to test the code under qemu, but I met two
build errors.
The first one is that __maybe_unused breaks the build below:
> +static __maybe_unused
> +void *sys_mmap(void *addr, size_t length, int prot, int flags, int fd,
> + off_t offset)
And indeed, __maybe_unused is not defined here in userland. The following
patch allows to go further:
diff --git a/tools/include/nolibc/arch-s390.h b/tools/include/nolibc/arch-s390.h
index 34b744e2f7d6..effae6e3d9e2 100644
--- a/tools/include/nolibc/arch-s390.h
+++ b/tools/include/nolibc/arch-s390.h
@@ -194,7 +194,7 @@ struct s390_mmap_arg_struct {
unsigned long offset;
};
-static __maybe_unused
+static __attribute__((unused))
void *sys_mmap(void *addr, size_t length, int prot, int flags, int fd,
off_t offset)
{
But with this addressed, I'm facing this next error:
$ make nolibc-test LDFLAGS= ARCH=s390 CC=/f/tc/nolibc/gcc-12.2.0-nolibc/s390-linux/bin/s390-linux-gcc
MKDIR sysroot/s390/include
make[1]: Entering directory '/g/public/linux/master/tools/include/nolibc'
make[2]: Entering directory '/g/public/linux/master'
make[2]: Leaving directory '/g/public/linux/master'
make[2]: Entering directory '/g/public/linux/master'
INSTALL /g/public/linux/master/tools/testing/selftests/nolibc/sysroot/sysroot/include
make[2]: Leaving directory '/g/public/linux/master'
make[1]: Leaving directory '/g/public/linux/master/tools/include/nolibc'
CC nolibc-test
/tmp/ccCzaBgD.s: Assembler messages:
/tmp/ccCzaBgD.s:9: Error: Unrecognized opcode: `lg'
/tmp/ccCzaBgD.s:12: Error: Unrecognized opcode: `lay'
/tmp/ccCzaBgD.s:15: Error: Unrecognized opcode: `lghi'
make: *** [Makefile:108: nolibc-test] Error 1
Thus I'm wondering if specific options are required for the compiler
(it's gcc 12.2.0 + binutils 2.39), if I'm not using the proper compiler,
or if there's anything wrong in the asm code (e.g. maybe by accident you
sent the patch from an earlier development branch), or anything else ?
FWIW I've used the patches from Paul's dev branch:
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/log/?h=dev
And the s390 toolchain from here:
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/12.2.0/
Thanks in advance for any help,
Willy
Hi Willy,
Willy Tarreau <w@1wt.eu> writes:
> On Fri, Dec 09, 2022 at 03:19:36PM +0100, Sven Schnelle wrote:
>> Use arch-x86_64 as a template. Not really different, but
>> we have our own mmap syscall which takes a structure instead
>> of discrete arguments.
> (...)
>
> This evening I downloaded an s390 toolchain from kernel.org's nolibc
> toolchains and expected to test the code under qemu, but I met two
> build errors.
>
> The first one is that __maybe_unused breaks the build below:
>
>> +static __maybe_unused
>> +void *sys_mmap(void *addr, size_t length, int prot, int flags, int fd,
>> + off_t offset)
>
> And indeed, __maybe_unused is not defined here in userland. The following
> patch allows to go further:
>
> diff --git a/tools/include/nolibc/arch-s390.h b/tools/include/nolibc/arch-s390.h
> index 34b744e2f7d6..effae6e3d9e2 100644
> --- a/tools/include/nolibc/arch-s390.h
> +++ b/tools/include/nolibc/arch-s390.h
> @@ -194,7 +194,7 @@ struct s390_mmap_arg_struct {
> unsigned long offset;
> };
>
> -static __maybe_unused
> +static __attribute__((unused))
> void *sys_mmap(void *addr, size_t length, int prot, int flags, int fd,
> off_t offset)
> {
Hrm, yes. I didn't thought about this macro not being present.
> But with this addressed, I'm facing this next error:
>
> $ make nolibc-test LDFLAGS= ARCH=s390 CC=/f/tc/nolibc/gcc-12.2.0-nolibc/s390-linux/bin/s390-linux-gcc
> MKDIR sysroot/s390/include
> make[1]: Entering directory '/g/public/linux/master/tools/include/nolibc'
> make[2]: Entering directory '/g/public/linux/master'
> make[2]: Leaving directory '/g/public/linux/master'
> make[2]: Entering directory '/g/public/linux/master'
> INSTALL /g/public/linux/master/tools/testing/selftests/nolibc/sysroot/sysroot/include
> make[2]: Leaving directory '/g/public/linux/master'
> make[1]: Leaving directory '/g/public/linux/master/tools/include/nolibc'
> CC nolibc-test
> /tmp/ccCzaBgD.s: Assembler messages:
> /tmp/ccCzaBgD.s:9: Error: Unrecognized opcode: `lg'
> /tmp/ccCzaBgD.s:12: Error: Unrecognized opcode: `lay'
> /tmp/ccCzaBgD.s:15: Error: Unrecognized opcode: `lghi'
> make: *** [Makefile:108: nolibc-test] Error 1
>
> Thus I'm wondering if specific options are required for the compiler
> (it's gcc 12.2.0 + binutils 2.39), if I'm not using the proper compiler,
> or if there's anything wrong in the asm code (e.g. maybe by accident you
> sent the patch from an earlier development branch), or anything else ?
Hmm, tried this on my x86 laptop, and it looks like there are two things
here:
The cross compiler needs -m64 to compile in 64bit mode. otherwise it
assumes 31bit mode, where both lg and lghi are not present. The other
thing is that lay was introduced with later generations of the
z/Architecture. The kernel compiles with z10 as minimum architecture, so
i'm leaning towards enforcing the same arch for nolibc. What do you think?
Hi Sven,
On Mon, Jan 02, 2023 at 09:17:04AM +0100, Sven Schnelle wrote:
> > But with this addressed, I'm facing this next error:
> >
> > $ make nolibc-test LDFLAGS= ARCH=s390 CC=/f/tc/nolibc/gcc-12.2.0-nolibc/s390-linux/bin/s390-linux-gcc
> > MKDIR sysroot/s390/include
> > make[1]: Entering directory '/g/public/linux/master/tools/include/nolibc'
> > make[2]: Entering directory '/g/public/linux/master'
> > make[2]: Leaving directory '/g/public/linux/master'
> > make[2]: Entering directory '/g/public/linux/master'
> > INSTALL /g/public/linux/master/tools/testing/selftests/nolibc/sysroot/sysroot/include
> > make[2]: Leaving directory '/g/public/linux/master'
> > make[1]: Leaving directory '/g/public/linux/master/tools/include/nolibc'
> > CC nolibc-test
> > /tmp/ccCzaBgD.s: Assembler messages:
> > /tmp/ccCzaBgD.s:9: Error: Unrecognized opcode: `lg'
> > /tmp/ccCzaBgD.s:12: Error: Unrecognized opcode: `lay'
> > /tmp/ccCzaBgD.s:15: Error: Unrecognized opcode: `lghi'
> > make: *** [Makefile:108: nolibc-test] Error 1
> >
> > Thus I'm wondering if specific options are required for the compiler
> > (it's gcc 12.2.0 + binutils 2.39), if I'm not using the proper compiler,
> > or if there's anything wrong in the asm code (e.g. maybe by accident you
> > sent the patch from an earlier development branch), or anything else ?
>
> Hmm, tried this on my x86 laptop, and it looks like there are two things
> here:
>
> The cross compiler needs -m64 to compile in 64bit mode. otherwise it
> assumes 31bit mode, where both lg and lghi are not present. The other
> thing is that lay was introduced with later generations of the
> z/Architecture.
Ah, this explains why along my various tests at some point I managed
to remove two of these errors (likely with -m64)!
> The kernel compiles with z10 as minimum architecture, so
> i'm leaning towards enforcing the same arch for nolibc. What do you think?
Sure, as long as this works for most users, that's likely fine.
Alternately, are there equivalent sequences of instructions that achieve
the same on older architectures, and would that be relevant ?
One future improvement I'll need will be to store the envp value into a
global "environ" variable, and run over it to catch the pointer that
follows the NULL and save it into the "_auxv" variable. I've done it for
all other archs here already:
https://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/nolibc.git/log/?h=20221227-nolibc-weak-4
I'll give it a try once I'm able to build and test your code, and may
ask you for some help if I don't succeed in doing it. If you want to do
it yourself, please have a look at the last commits adding environ and
auxv to any arch of your choice, such as x86_64.
Thanks!
Willy
Willy Tarreau <w@1wt.eu> writes:
> On Mon, Jan 02, 2023 at 09:17:04AM +0100, Sven Schnelle wrote:
>> The kernel compiles with z10 as minimum architecture, so
>> i'm leaning towards enforcing the same arch for nolibc. What do you think?
>
> Sure, as long as this works for most users, that's likely fine.
> Alternately, are there equivalent sequences of instructions that achieve
> the same on older architectures, and would that be relevant ?
Well, it's only one instruction that needs to be changed - we could also
use aghi to do the same thing. Maybe that's better.
Also i will add -m64 to the testing Makefile, it shouldn't hurt.
> One future improvement I'll need will be to store the envp value into a
> global "environ" variable, and run over it to catch the pointer that
> follows the NULL and save it into the "_auxv" variable. I've done it for
> all other archs here already:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/nolibc.git/log/?h=20221227-nolibc-weak-4
>
> I'll give it a try once I'm able to build and test your code, and may
> ask you for some help if I don't succeed in doing it. If you want to do
> it yourself, please have a look at the last commits adding environ and
> auxv to any arch of your choice, such as x86_64.
Ok, thanks for the Heads-Up. I'll take a look. I think i would send this
as a separate Patch, so we get the initial support done first if that's ok.
On Mon, Jan 02, 2023 at 10:33:08AM +0100, Sven Schnelle wrote:
> Willy Tarreau <w@1wt.eu> writes:
>
> > On Mon, Jan 02, 2023 at 09:17:04AM +0100, Sven Schnelle wrote:
> >> The kernel compiles with z10 as minimum architecture, so
> >> i'm leaning towards enforcing the same arch for nolibc. What do you think?
> >
> > Sure, as long as this works for most users, that's likely fine.
> > Alternately, are there equivalent sequences of instructions that achieve
> > the same on older architectures, and would that be relevant ?
>
> Well, it's only one instruction that needs to be changed - we could also
> use aghi to do the same thing. Maybe that's better.
>
> Also i will add -m64 to the testing Makefile, it shouldn't hurt.
>
> > One future improvement I'll need will be to store the envp value into a
> > global "environ" variable, and run over it to catch the pointer that
> > follows the NULL and save it into the "_auxv" variable. I've done it for
> > all other archs here already:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/nolibc.git/log/?h=20221227-nolibc-weak-4
> >
> > I'll give it a try once I'm able to build and test your code, and may
> > ask you for some help if I don't succeed in doing it. If you want to do
> > it yourself, please have a look at the last commits adding environ and
> > auxv to any arch of your choice, such as x86_64.
>
> Ok, thanks for the Heads-Up. I'll take a look. I think i would send this
> as a separate Patch, so we get the initial support done first if that's ok.
Yes absolutely, that was also my intent. I have not yet submitted this
series.
Thanks!
Willy
new file mode 100644
@@ -0,0 +1,213 @@
+/* SPDX-License-Identifier: LGPL-2.1 OR MIT */
+/*
+ * s390 specific definitions for NOLIBC
+ */
+
+#ifndef _NOLIBC_ARCH_S390_H
+#define _NOLIBC_ARCH_S390_H
+#include <asm/unistd.h>
+
+/* O_* macros for fcntl/open are architecture-specific */
+#define O_RDONLY 0
+#define O_WRONLY 1
+#define O_RDWR 2
+#define O_CREAT 0x40
+#define O_EXCL 0x80
+#define O_NOCTTY 0x100
+#define O_TRUNC 0x200
+#define O_APPEND 0x400
+#define O_NONBLOCK 0x800
+#define O_DIRECTORY 0x10000
+
+/* The struct returned by the stat() syscall, equivalent to stat64(). The
+ * syscall returns 116 bytes and stops in the middle of __unused.
+ */
+
+struct sys_stat_struct {
+ unsigned long st_dev;
+ unsigned long st_ino;
+ unsigned long st_nlink;
+ unsigned int st_mode;
+ unsigned int st_uid;
+ unsigned int st_gid;
+ unsigned int __pad1;
+ unsigned long st_rdev;
+ unsigned long st_size;
+ unsigned long st_atime;
+ unsigned long st_atime_nsec;
+ unsigned long st_mtime;
+ unsigned long st_mtime_nsec;
+ unsigned long st_ctime;
+ unsigned long st_ctime_nsec;
+ unsigned long st_blksize;
+ long st_blocks;
+ unsigned long __unused[3];
+};
+
+/* Syscalls for s390:
+ * - registers are 64-bit
+ * - syscall number is passed in r1
+ * - arguments are in r2-r7
+ * - the system call is performed by calling the svc instruction
+ * - syscall return value is in r2
+ * - r1 and r2 are clobbered, others are preserved.
+ *
+ * Link s390 ABI: https://github.com/IBM/s390x-abi
+ *
+ */
+
+#define my_syscall0(num) \
+({ \
+ register long _num __asm__ ("1") = (num); \
+ register long _rc __asm__ ("2"); \
+ \
+ __asm__ volatile ( \
+ "svc 0\n" \
+ : "=d"(_rc) \
+ : "d"(_num) \
+ : "memory", "cc" \
+ ); \
+ _rc; \
+})
+
+#define my_syscall1(num, arg1) \
+({ \
+ register long _num __asm__ ("1") = (num); \
+ register long _arg1 __asm__ ("2") = (long)(arg1); \
+ \
+ __asm__ volatile ( \
+ "svc 0\n" \
+ : "+d"(_arg1) \
+ : "d"(_num) \
+ : "memory", "cc" \
+ ); \
+ _arg1; \
+})
+
+#define my_syscall2(num, arg1, arg2) \
+({ \
+ register long _num __asm__ ("1") = (num); \
+ register long _arg1 __asm__ ("2") = (long)(arg1); \
+ register long _arg2 __asm__ ("3") = (long)(arg2); \
+ \
+ __asm__ volatile ( \
+ "svc 0\n" \
+ : "+d"(_arg1) \
+ : "d"(_arg2), "d"(_num) \
+ : "memory", "cc" \
+ ); \
+ _arg1; \
+})
+
+#define my_syscall3(num, arg1, arg2, arg3) \
+({ \
+ register long _num __asm__ ("1") = (num); \
+ register long _arg1 __asm__ ("2") = (long)(arg1); \
+ register long _arg2 __asm__ ("3") = (long)(arg2); \
+ register long _arg3 __asm__ ("4") = (long)(arg3); \
+ \
+ __asm__ volatile ( \
+ "svc 0\n" \
+ : "+d"(_arg1) \
+ : "d"(_arg2), "d"(_arg3), "d"(_num) \
+ : "memory", "cc" \
+ ); \
+ _arg1; \
+})
+
+#define my_syscall4(num, arg1, arg2, arg3, arg4) \
+({ \
+ register long _num __asm__ ("1") = (num); \
+ register long _arg1 __asm__ ("2") = (long)(arg1); \
+ register long _arg2 __asm__ ("3") = (long)(arg2); \
+ register long _arg3 __asm__ ("4") = (long)(arg3); \
+ register long _arg4 __asm__ ("5") = (long)(arg4); \
+ \
+ __asm__ volatile ( \
+ "svc 0\n" \
+ : "+d"(_arg1) \
+ : "d"(_arg2), "d"(_arg3), "d"(_arg4), "d"(_num) \
+ : "memory", "cc" \
+ ); \
+ _arg1; \
+})
+
+#define my_syscall5(num, arg1, arg2, arg3, arg4, arg5) \
+({ \
+ register long _num __asm__ ("1") = (num); \
+ register long _arg1 __asm__ ("2") = (long)(arg1); \
+ register long _arg2 __asm__ ("3") = (long)(arg2); \
+ register long _arg3 __asm__ ("4") = (long)(arg3); \
+ register long _arg4 __asm__ ("5") = (long)(arg4); \
+ register long _arg5 __asm__ ("6") = (long)(arg5); \
+ \
+ __asm__ volatile ( \
+ "svc 0\n" \
+ : "+d"(_arg1) \
+ : "d"(_arg2), "d"(_arg3), "d"(_arg4), "d"(_arg5), \
+ "d"(_num) \
+ : "memory", "cc" \
+ ); \
+ _arg1; \
+})
+
+#define my_syscall6(num, arg1, arg2, arg3, arg4, arg5, arg6) \
+({ \
+ register long _num __asm__ ("1") = (num); \
+ register long _arg1 __asm__ ("2") = (long)(arg1); \
+ register long _arg2 __asm__ ("3") = (long)(arg2); \
+ register long _arg3 __asm__ ("4") = (long)(arg3); \
+ register long _arg4 __asm__ ("5") = (long)(arg4); \
+ register long _arg5 __asm__ ("6") = (long)(arg5); \
+ register long _arg6 __asm__ ("7") = (long)(arg6); \
+ \
+ __asm__ volatile ( \
+ "svc 0\n" \
+ : "+d"(_arg1) \
+ : "d"(_arg2), "d"(_arg3), "d"(_arg4), "d"(_arg5), \
+ "d"(_arg6), "d"(_num) \
+ : "memory", "cc" \
+ ); \
+ _arg1; \
+})
+
+/* startup code */
+__asm__ (".section .text\n"
+ ".weak _start\n"
+ "_start:\n"
+ "lg %r2,0(%r15)\n" /* argument count */
+ "la %r3,8(%r15)\n" /* argument pointers */
+ "la %r4,24(%r15)\n" /* environment pointers */
+ "lay %r15,-160(%r15)\n" /* allocate new stackframe */
+ "xc 0(8,%r15),0(%r15)\n" /* clear backchain */
+ "brasl %r14,main\n" /* ret value of main is arg to exit */
+ "lghi %r1,1\n" /* __NR_exit */
+ "svc 0\n"
+ "");
+
+struct s390_mmap_arg_struct {
+ unsigned long addr;
+ unsigned long len;
+ unsigned long prot;
+ unsigned long flags;
+ unsigned long fd;
+ unsigned long offset;
+};
+
+static __maybe_unused
+void *sys_mmap(void *addr, size_t length, int prot, int flags, int fd,
+ off_t offset)
+{
+ struct s390_mmap_arg_struct args = {
+ .addr = (unsigned long)addr,
+ .len = (unsigned long)length,
+ .prot = prot,
+ .flags = flags,
+ .fd = fd,
+ .offset = (unsigned long)offset
+ };
+
+ return (void *)my_syscall1(__NR_mmap, &args);
+}
+#define sys_mmap sys_mmap
+#endif // _NOLIBC_ARCH_S390_H
@@ -27,6 +27,8 @@
#include "arch-mips.h"
#elif defined(__riscv)
#include "arch-riscv.h"
+#elif defined(__s390x__)
+#include "arch-s390x.h"
#endif
#endif /* _NOLIBC_ARCH_H */
@@ -686,6 +686,7 @@ int mknod(const char *path, mode_t mode, dev_t dev)
#define MAP_FAILED ((void *)-1)
#endif
+#ifndef sys_mmap
static __attribute__((unused))
void *sys_mmap(void *addr, size_t length, int prot, int flags, int fd,
off_t offset)
@@ -707,6 +708,7 @@ void *sys_mmap(void *addr, size_t length, int prot, int flags, int fd,
return (void *)my_syscall6(n, addr, length, prot, flags, fd, offset);
#endif
}
+#endif
static __attribute__((unused))
void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset)