Weirdness in disassembly

["Michael Chapman" <Michael.Chapman@synopsys.com>]

[-- 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: