This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Another x86_64 disassembler crash
>Something is still strange in my testcase; the 32-bit and 64-bit
>disassemblers produce different output, but the differences are of
the
>forms:
>
>-ffffffff8055fb2e: 2e cs
>-ffffffff8055fb2f: 2e cs
>-ffffffff8055fb30: 2e cs
>-ffffffff8055fb31: 2e 2e 2e 2e 2e 2e 2e or
%cs:0xffffffffffffffee(%rcx),%ch
>-ffffffff8055fb38: 2e 2e 2e 2e 2e 2e 2e
>-ffffffff8055fb3f: 2e 2e 2e 2e 2e 2e 0a
>-ffffffff8055fb46: 00 00
>-ffffffff8055fb48: 3c 37 cmp $0x37,%al
>+ffffffff8055fb2e: 2e 2e 2e 2e 2e 2e 2e or %cs:(%rax),%al
>+ffffffff8055fb35: 2e 2e 2e 2e 2e 2e 2e
>+ffffffff8055fb3c: 2e 2e 2e 2e 2e 2e 2e
>+ffffffff8055fb43: 2e 2e 0a 00
>+ffffffff8055fb47: 00 3c 37 add %bh,(%rdi,%rsi,1)
This difference is caused by a buffer overflow, which triggers (due to
alignment differences) later on 64-bits than on 32. Preparing a
patch...
>and
>
>-ffffffff805be630: 43 17 rexYZ popq %dl
>+ffffffff805be630: 43 17 rexYZ popq %bp,%si
This one I can't explain at all. Opcode 0x17 is invalid in 64-bit mode,
and clearly marked as such in the tables. Whatever binutils version I
use, I get "rexYZ (bad)" as expected.
Bottom line is, more context might be needed to understand why things
are going wrong...
Jan