When assembler source contains "nop" (no-operation) instruction without an operand, gas on s390x produces an error a.s: Assembler messages: a.s:2: Error: missing operand In my opinion "nop" should translate into a no-operation machine instruction without requiring any operand in the assembler sources. Version-Release number of selected component (if applicable): binutils-2.19.51.0.2-17.fc11 also present in RHEL-4 and RHEL-5 binutils-2.15.92.0.2-24 (EL4) binutils-2.17.50.0.6-12.el5 Reproducer is: as << EOF .section code nop EOF and it results into: {standard input}: Assembler messages: {standard input}:2: Error: missing operand Aditional info: Real world example of breakage is build of postgresql (https://s390.koji.fedoraproject.org/koji/taskinfo?taskID=82106) with static probes where the probe (from sys/sdt.h) translates into ====== .LVL471: #APP # 1551 "xact.c" 1 .section .probes .align 8 1: .asciz "transaction__start" .align 4 .int 0x31425250 .align 8 .long 1b .align 8 .long 2f .previous # 0 "" 2 #NO_APP l %r1,164(%r15) #APP # 1551 "xact.c" 1 2: nop /* %r1 */ # 0 "" 2 #NO_APP ===== and xact.c: Assembler messages: xact.c:2089: Error: missing operand xact.c:1552: Error: missing operand xact.c:1679: Error: missing operand These lines from opcodes/s390-opc.txt are related to "nop": 0700 nopr RR_0R "no operation" g5 esa,zarch 0700 b*8r RR_0R "conditional branch" g5 esa,zarch 4700 nop RX_0RRD "no operation" g5 esa,zarch 4700 b*8 RX_0RRD "conditional branch" g5 esa,zarch Even the Linux kernel defines a nop in /arch/s390/include/asm/system.h as #define nop() asm volatile("nop") but it's not probably used, otherwise it would break the build.
Created attachment 348283 [details] Allow NOP instruction without any operands
Hi Dan, Please could you try out the uploaded patch and let me know if this fixes the problem for you. Cheers Nick
(In reply to comment #2) > Please could you try out the uploaded patch and let me know if this fixes the > problem for you. I have used a cross-assembler on the file and it compiles without error. I have only a question whether this "hack" guarantees that the proper "no-operation" opcode will be generated?
Hi Dan, The patch will generate a proper nop instruction. But as it turns out the patch is unnecessary. The s390x maintainer for the binutils port has recently installed a different patch into the FSF sources (which makes the arguments to the NOP instruction opional) and this has now been imported into rawhide. Cheers Nick
Hi Nick, it looks like there's a parallel channel directly into IBM from our bugzilla :-) 2 days from a report to a fix. Thanks anyway. Dan