Re: [PATCH 2/5] nolibc: add support for s390

[Willy Tarreau <w@1wt.eu>]

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