xorg-server FTBFS under S390 with error Unrecognized opcode: `sti'

[José Parrella]

Greetings everyone,

I've been recently interested in RC #386938 (xorg-server - FTBFS: Error:
Unrecognized opcode: `sti') It seems to me that the sti opcode isn't
being recognized because one of three reasons:

a) Current versions of binutils and gcc in Sid interoperate badly (which
seems possible and actually other -already solved- bugs give hints on
this direction, like #376832)
b) Somehow the compiler isn't producing valid .s code for the ESA/390
(which is quite utopic indeed and would be apocalyptic)
c) Definitions for the unrecognized routines are not present in the
build environment. This would mean that the include/asm-s390/system.h
(provided by libklibc-dev or other kernel headers) isn't present at
build time.

Besides from the fact that is not Debian/S390's Team to test patches,
could anyone point out any reasons that might be producing this FTBFS?
And maybe someone could be able to test if xorg-server can build from
source including a system.h file in raptor or any other s390 machine.

Thank you very much for your time,
Jose

[Arnd Bergmann]

Post by José Parrella
Greetings everyone,
Unrecognized opcode: `sti') It seems to me that the sti opcode isn't
a) Current versions of binutils and gcc in Sid interoperate badly (which
seems possible and actually other -already solved- bugs give hints on
this direction, like #376832)
b) Somehow the compiler isn't producing valid .s code for the ESA/390
(which is quite utopic indeed and would be apocalyptic)
c) Definitions for the unrecognized routines are not present in the
build environment. This would mean that the include/asm-s390/system.h
(provided by libklibc-dev or other kernel headers) isn't present at
build time.
Besides from the fact that is not Debian/S390's Team to test patches,
could anyone point out any reasons that might be producing this FTBFS?
And maybe someone could be able to test if xorg-server can build from
source including a system.h file in raptor or any other s390 machine.

Wasn't this fixed upstream as of this?
http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=f7919c287936f55569c2301ebb1b5f52358e70fa

Arnd <><

[Bastian Blank]

Post by José Parrella
a) Current versions of binutils and gcc in Sid interoperate badly (which
seems possible and actually other -already solved- bugs give hints on
this direction, like #376832)

Nope, this was s390x specific assembler instructions for s390.

Post by José Parrella
b) Somehow the compiler isn't producing valid .s code for the ESA/390
(which is quite utopic indeed and would be apocalyptic)
c) Definitions for the unrecognized routines are not present in the
build environment. This would mean that the include/asm-s390/system.h
(provided by libklibc-dev or other kernel headers) isn't present at
build time.

include/asm-s390/system.h is not for use in userspace and don't provide
something which may look like sti.

Also you forget an option
d) sti does not exist. (I just checked the opcode table, it really does
not exist)

Bastian

[José Parrella]

Post by Bastian Blank
d) sti does not exist. (I just checked the opcode table, it really does
not exist)

I originally thought that, yes (that would explain why avoiding iopl and
ioperm solves the unrecognized opcode thing). I think I was confused
because David Nusinow uploaded a new version with your patches to
unstable, then reverted to the old version and uploaded to experimental,
and meanwhile the last buildd log for the package in s390 failed [1]

Thank you for your patience,
Jose

[1]
http://buildd.debian.org/build.php?&pkg=xorg-server&ver=2%3A1.0.2-10&arch=s390&file=log

[Arnd Bergmann]

Post by José Parrella

Post by Bastian Blank
d) sti does not exist. (I just checked the opcode table, it really does
not exist)

I originally thought that, yes (that would explain why avoiding iopl and
ioperm solves the unrecognized opcode thing). I think I was confused
because David Nusinow uploaded a new version with your patches to
unstable, then reverted to the old version and uploaded to experimental,
and meanwhile the last buildd log for the package in s390 failed [1]

Just to make this clear:

s390 does not have graphics hardware that linux could use
s390 does not have mmio hardware
s390 does not have iopl()
s390 can not disable interrupts from user space

The correct solution to this problem would be to not even
try to build any X server except Xvfb and Xnest.

Arnd <><

[José Parrella]

Post by Arnd Bergmann
s390 does not have iopl()
s390 can not disable interrupts from user space

Great. I didn't knew that (that's why I were asking in the first place),
but I learned that from Bastian's patch, IBM's Principles of Operation
and your comment. Thanks.

Post by Arnd Bergmann
The correct solution to this problem would be to not even
try to build any X server except Xvfb and Xnest.

Some people exchanged ideas about that in the BTS [1]. The xorg-server
source package provides dummy video/input drivers, and it also provides
xvfb and xnest. The bugs we were talking about were making it impossible
to build those binary packages for the s390 architecture. Please note
that I'm not an X Strike Force member, nor I'm a freak who wants
everything compiled everyhere. I was just wondering about the bug.

Have a nice day,
Jose

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=362641