clang error: cmp literal, memaddress is ambiguous

[GoogleCodeExporter]

clang's integrated assembler emits the following error when building the 
seccomp sandbox:

/tmp/cc-DNyGz3.s:155:9: error: ambiguous instructions require an explicit 
suffix (could be 'cmpb', 'cmpw', 'cmpl', or 'cmpq')
        cmp $0, 0(%rax)
        ^
/tmp/cc-DNyGz3.s:157:9: error: ambiguous instructions require an explicit 
suffix (could be 'cmpb', 'cmpw', 'cmpl', or 'cmpq')
        cmp $1, 0(%rax)

This patch fixes the problem:

Index: fault_handler_i386.S
===================================================================
--- fault_handler_i386.S    (revision 153)
+++ fault_handler_i386.S    (working copy)
@@ -178,9 +178,9 @@
         // callers might be confused by this and will need fixing for running
         // inside of the seccomp sandbox.
      20:lea  playground$sa_segv, %eax
-        cmp  $0, 0(%eax)         // SIG_DFL
+        cmpw $0, 0(%eax)         // SIG_DFL
         jz   21f
-        cmp  $1, 0(%eax)         // SIG_IGN
+        cmpw  $1, 0(%eax)         // SIG_IGN
         jnz  22f                 // can't really ignore synchronous signals

Original issue reported on code.google.com by thakis@google.com on 26 Jan 2011 at 4:03

[GoogleCodeExporter]

That should be cmpl rather than cmpw.  The current code disassembles to:

 247:   8d 05 00 00 00 00       lea    0x0,%eax
                        249: R_386_32   playground$sa_segv
 24d:   83 38 00                cmpl   $0x0,(%eax)
 250:   74 05                   je     257 <playground$segvSignalHandler+0x257>
 252:   83 38 01                cmpl   $0x1,(%eax)
 255:   75 0d                   jne    264 <playground$segvSignalHandler+0x264>

It is fetching a function pointer from the first member of "struct 
kernel_sigaction".

Original comment by mseaborn@chromium.org on 27 Jan 2011 at 2:27

• Changed state: Accepted

[GoogleCodeExporter]

Argh, sorry. I meant "cmp 4 bytes", I always forget that "w" is 2 bytes in x86 
asm. You're right.

Original comment by thakis@chromium.org on 27 Jan 2011 at 3:23

[GoogleCodeExporter]

It appears this warning has found a real bug in the x86-64 version!  The 
original code disassembles to:

 219:   48 8b 05 00 00 00 00    mov    0x0(%rip),%rax        # 220 <playground$segvSignalHandler+0x220>
                        21c: R_X86_64_GOTPCREL  playground$sa_segv-0x4
 220:   83 38 00                cmpl   $0x0,(%rax)
 223:   74 05                   je     22a <playground$segvSignalHandler+0x22a>
 225:   83 38 01                cmpl   $0x1,(%rax)
 228:   75 09                   jne    233 <playground$segvSignalHandler+0x233>

so it looks like the assembler defaults to "l" (32-bit) rather than "q" 
(64-bit).  The bug isn't likely to be tickled, and it's not in trusted code, 
but it's a bug nonetheless.

Original comment by mseaborn@chromium.org on 27 Jan 2011 at 9:46

[GoogleCodeExporter]

Fixed in r154.

Original comment by mseaborn@chromium.org on 27 Jan 2011 at 10:43

• Changed state: Fixed