This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[bug: amd64] Improper translation of a twisted statement

Dear all,

I am currently making some tests for a tool using libopcodes to
disassemble binary file and I try a few twisted cases.

What follows is "funny" bug, but very unlikely to be raised one day (so
"Don't panic!" as Douglas Adams would say).

Here is a statement that I compile with gas (through gcc with: 'gcc -m64
-march=i686 -c -o myobjectfile.o myassemblycode.s'):

	## Twisted PUSH imm64
	data16 pushq $0x31415926
	data16 push %fs

As you can notice, I ask for both 16bits-mode data (with data16) and
64bits-mode (with the pushq). So, this line of code has almost no chance
to appear in reality (except if the coder do not know what he is doing).

But, the surprise comes when trying to disassemble it with objdump:

   0:	66 68 26 59          	pushw  $0x5926
   4:	41 31 66 0f          	xor    %esp,0xf(%r14)
   8:	a0                   	.byte 0xa0

It looks like the compiler did applied the 'data16' by selecting the
'pushw' instruction, but did totally forgot to cut out the rest of the
operand $0x31415926 which still lays in the memory and is interpreted as
an instruction (and messing up the next instruction).

Again, this is a very particular case, but my guess would have been to
cut out the immediate value and throw a warning about it.

Or, did I totally misunderstood what I did ?

Emmanuel Fleury

The only difference between the saint and the sinner is that
every saint has a past and every sinner has a future.
  -- Oscar Wilde

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]