Weirdness in disassembly

Weirdness in disassembly

[Michael Chapman]

[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]

I have just started out to experiment with cgen.

I have instructions which are 16 and 32 bits long.
The assembler generates the right instructions with
the right lengths.

However when I do a dissassembly with objdump -D I get
only the first 16 bits decoded for 32 bit instructions
and (in my very very simple test case) *unknown* when it
tries to decode the second 16 bits of the 32 bit 
instruction.

If I change 

static int
extract_insn_normal (cd, insn, ex_info, insn_value, fields, pc)

in the generated dw32-ibld.c file to always return 32 bits,

ie. 
  return 32;
instead of the generated

  /* We recognized and successfully extracted this insn.  */
  return CGEN_INSN_BITSIZE (insn);

the correct instructions are decoded (i.e. it does not skip
any instructions after a 16 bit instruction), indeed the results
are correct apart from the fact that it prints out two extra
instruction bytes for 16 bit instructions.

The attached files are generated like this:-
   dw32as -a test.asm > test.lst
a.out was generated by
   dw32as test.asm

Then with the unmodified dw32-ibld.c file
   dw32objdump -D a.out > test.dmp

and with the modified dw32-ibld.c file
   dw32objdump -D a.out > test.dmp32

I am not sure where the Gremlin is.

Obviously the instruction length is being correctly decoded in 
at least one place (where ever it is which decides how many 
bytes have been consumed by an instruction), but not in 
the extract_insn_normal function dw32-ibld.c.

The instruction bit length is correct in the CGEN_IFMT structs
generated in dw32-opc.c

Any ideas?

Mike Chapman

PS I am using binutils 2.13 release
and a recently checked out cgen from 
:pserver:anoncvs@sources.redhat.com:/cvs/src

I can send a whole load more of the files if you are 
interested.


[-- Attachment #2: test.asm --]
[-- Type: application/octet-stream, Size: 182 bytes --]


l1:      mov r1, r2
l2:      mov r3, r4                
l3:      mov r5, #0x1234
l4:      mov r6, #0x5678
l5:      mov r7, r8
l6:      mov r9, r10
        
                
        

[-- Attachment #3: a.out --]
[-- Type: application/octet-stream, Size: 571 bytes --]

[-- Attachment #4: test.lst --]
[-- Type: application/octet-stream, Size: 752 bytes --]

Dw32 GAS  test.asm 			page 1


   1              	
   2 0000 0012     	l1:      mov r1, r2
   3 0002 0034     	l2:      mov r3, r4                
   4 0004 10503412 	l3:      mov r5, #0x1234
   5 0008 10607856 	l4:      mov r6, #0x5678
   6 000c 0078     	l5:      mov r7, r8
   7 000e 009A     	l6:      mov r9, r10
   8              	        
   9              	                
\fDw32 GAS  test.asm 			page 2


DEFINED SYMBOLS
            test.asm:2      .text:00000000 l1
            test.asm:3      .text:00000002 l2
            test.asm:4      .text:00000004 l3
            test.asm:5      .text:00000008 l4
            test.asm:6      .text:0000000c l5
            test.asm:7      .text:0000000e l6

NO UNDEFINED SYMBOLS

[-- Attachment #5: test.dmp --]
[-- Type: application/octet-stream, Size: 454 bytes --]


a.out:     file format elf32-dw32

Disassembly of section .text:

00000000 <l1>:
   0:	00 12       	mov r1,r2

00000002 <l2>:
   2:	00 34       	mov r3,r4

00000004 <l3>:
   4:	10 50       	mov r5,#0x0
   6:	34 12       	*unknown*

00000008 <l4>:
   8:	10 60       	mov r6,#0x0
   a:	78 56       	*unknown*

0000000c <l5>:
   c:	00 78       	mov r7,r8

0000000e <l6>:
   e:	00 9a       	mov r9,r10
Disassembly of section .data:

[-- Attachment #6: test.dmp32 --]
[-- Type: application/octet-stream, Size: 394 bytes --]


a.out:     file format elf32-dw32

Disassembly of section .text:

00000000 <l1>:
   0:	00 12 00 34 	mov r1,r2

00000002 <l2>:
   2:	00 34 10 50 	mov r3,r4

00000004 <l3>:
   4:	10 50 34 12 	mov r5,#0x0

00000008 <l4>:
   8:	10 60 78 56 	mov r6,#0x0

0000000c <l5>:
   c:	00 78 00 9a 	mov r7,r8

0000000e <l6>:
   e:	00 9a 00 00 	mov r9,r10
Disassembly of section .data:

Re: Weirdness in disassembly

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

Hi -

On Fri, Sep 27, 2002 at 04:46:42PM +0200, Michael Chapman wrote:
> I have just started out to experiment with cgen.

Welcome!

> I have instructions which are 16 and 32 bits long.
> The assembler generates the right instructions with
> the right lengths. [...]

The choice of parameters in the define-isa clause is crucial
for variable-length instruction sets.  If any of your 32-bit
instructions contain any fixed bit patterns in the second 16
bits, you need to set "base-insn-bitsize 32", since opcodes/simulators
will need to fetch 32 bits to uniquely identify a cgen-level
instruction.  Setting that to 16 could explain what you're seeing.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

RE: Weirdness in disassembly

[Michael Chapman]

Hi,

That was a quick answer!

No - there are no fixed bit patterns in the second 16 bits.
They are just used for offsets or absolute addresses.

Everything is little endian.

I just changed what you said - it does not seemt to change
anything - (yes I regenerated the files!) 

It is true a haven't really
understood what the lengths really all mean. I have at the
moment:-

(define-isa
  ; Name of the ISA.
  (name dw32)
  (comment "Basic DW32 instruction set")
  
  ; (Size of unknown instructions)
  (default-insn-word-bitsize 16)

  ; Shortest instruction is 16 bits
  (default-insn-bitsize 16)
  (base-insn-bitsize 32)
)

Any more ideas?

Mike


-----Original Message-----
From: Frank Ch. Eigler [mailto:fche@redhat.com]
Sent: Friday, 27 September, 2002 16:51
To: Michael Chapman
Cc: cgen@sources.redhat.com
Subject: Re: Weirdness in disassembly


Hi -

On Fri, Sep 27, 2002 at 04:46:42PM +0200, Michael Chapman wrote:
> I have just started out to experiment with cgen.

Welcome!

> I have instructions which are 16 and 32 bits long.
> The assembler generates the right instructions with
> the right lengths. [...]

The choice of parameters in the define-isa clause is crucial
for variable-length instruction sets.  If any of your 32-bit
instructions contain any fixed bit patterns in the second 16
bits, you need to set "base-insn-bitsize 32", since opcodes/simulators
will need to fetch 32 bits to uniquely identify a cgen-level
instruction.  Setting that to 16 could explain what you're seeing.


- FChE

Re: Weirdness in disassembly

[Frank Ch. Eigler]

[-- Attachment #1: Type: text/plain, Size: 873 bytes --]

Hi -

On Fri, Sep 27, 2002 at 05:19:33PM +0200, Michael Chapman wrote:
> [...]
> My mistake somewhere. Not sure when though. The opcode 
> for the 32 bit instruction is the same as that for 
> the 16 bit variant of it (well it was in how I had typed
> it)! 
> 
> Fixed that now. And I now get the correct disassembly.

Good stuff.
CGEN would benefit from improved detection of this sort of error.
If you were to generate a simulator kernel, you'd have been told of
the ambiguity.

> Now what values should I have for the instruction lengths?
> Obviously at least one of them has to be 16 bits for
> not skipping over to much when decoding junk.

Since a real program should not contain junk, a specific choice for
the other variables is not that important.  Go with whatever
working numbers you prefer.  The base-insn-size is the biggie.


- FChE

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]