Messages in this thread | | | Date | Mon, 2 Jan 2023 09:41:22 +0100 | From | Willy Tarreau <> | Subject | Re: [PATCH 2/5] nolibc: add support for s390 |
| |
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
| |