Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Sven Schnelle <svens@linux.ibm.com>
To:     Willy Tarreau <w@1wt.eu>
Cc:     "Paul E . McKenney" <paulmck@kernel.org>,
        Josh Triplett <josh@joshtriplett.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
        Lai Jiangshan <jiangshanlai@gmail.com>,
        linux-kernel@vger.kernel.org, hca@linux.ibm.com
Subject: Re: [PATCH 2/5] nolibc: add support for s390
References: <20221209141939.3634586-1-svens@linux.ibm.com>
        <20221209141939.3634586-3-svens@linux.ibm.com>
        <20221227213530.GA6390@1wt.eu>
Date:   Mon, 02 Jan 2023 09:17:04 +0100
In-Reply-To: <20221227213530.GA6390@1wt.eu> (Willy Tarreau's message of "Tue,
        27 Dec 2022 22:35:30 +0100")
Message-ID: <yt9dilhpjqpr.fsf@linux.ibm.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

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?