From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22906 invoked by alias); 27 Sep 2002 14:46:51 -0000 Mailing-List: contact cgen-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sources.redhat.com Received: (qmail 22896 invoked from network); 27 Sep 2002 14:46:48 -0000 Received: from unknown (HELO boden.synopsys.com) (204.176.20.19) by sources.redhat.com with SMTP; 27 Sep 2002 14:46:48 -0000 Received: from maiden.synopsys.com (maiden.synopsys.com [146.225.100.170]) by boden.synopsys.com (Postfix) with ESMTP id E02DDE30D for ; Fri, 27 Sep 2002 07:46:47 -0700 (PDT) Received: from fr02.synopsys.com (localhost [127.0.0.1]) by maiden.synopsys.com (8.9.1/8.9.1) with ESMTP id HAA08442 for ; Fri, 27 Sep 2002 07:47:16 -0700 (PDT) Received: from michaelclap (localhost [127.0.0.1]) by fr02.synopsys.com (8.9.1/8.9.1) with SMTP id QAA10178 for ; Fri, 27 Sep 2002 16:46:42 +0200 (MET DST) From: "Michael Chapman" To: Subject: Weirdness in disassembly Date: Fri, 27 Sep 2002 07:46:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_01C26645.75553450" X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-SW-Source: 2002-q3/txt/msg00077.txt.bz2 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C26645.75553450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-length: 1769 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. ------=_NextPart_000_0006_01C26645.75553450 Content-Type: application/octet-stream; name="test.asm" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="test.asm" Content-length: 182 l1: mov r1, r2 l2: mov r3, r4 l3: mov r5, #0x1234 l4: mov r6, #0x5678 l5: mov r7, r8 l6: mov r9, r10 ------=_NextPart_000_0006_01C26645.75553450 Content-Type: application/octet-stream; name="a.out" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="a.out" Content-length: 777 f0VMRgEBAQAAAAAAAAAAAAEAMt0BAAAAAAAAAAAAAABwAAAAAAAAADQAAAAA ACgABwAEAAASADQQUDQSEGB4VgB4AJoALnN5bXRhYgAuc3RydGFiAC5zaHN0 cnRhYgAudGV4dAAuZGF0YQAuYnNzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAbAAAAAQAAAAYAAAAAAAAANAAAABAAAAAAAAAA AAAAAAEAAAAAAAAAIQAAAAEAAAADAAAAAAAAAEQAAAAAAAAAAAAAAAAAAAAB AAAAAAAAACcAAAAIAAAAAwAAAAAAAABEAAAAAAAAAAAAAAAAAAAAAQAAAAAA AAARAAAAAwAAAAAAAAAAAAAARAAAACwAAAAAAAAAAAAAAAEAAAAAAAAAAQAA AAIAAAAAAAAAAAAAAIgBAACgAAAABgAAAAoAAAAEAAAAEAAAAAkAAAADAAAA AAAAAAAAAAAoAgAAEwAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAwABAAAAAAAAAAAAAAAAAAMAAgAAAAAAAAAAAAAA AAADAAMAAQAAAAAAAAAAAAAAAAABAAQAAAACAAAAAAAAAAAAAQAHAAAABAAA AAAAAAAAAAEACgAAAAgAAAAAAAAAAAABAA0AAAAMAAAAAAAAAAAAAQAQAAAA DgAAAAAAAAAAAAEAAGwxAGwyAGwzAGw0AGw1AGw2AA== ------=_NextPart_000_0006_01C26645.75553450 Content-Type: application/octet-stream; name="test.lst" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="test.lst" Content-length: 1002 Dw32 GAS test.asm page 1=0A= =0A= =0A= 1=20=20=20=20=20=20=20=20=20=20=20=20=20=20=09=0A= 2 0000 0012 l1: mov r1, r2=0A= 3 0002 0034 l2: mov r3, r4=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=0A= 4 0004 10503412 l3: mov r5, #0x1234=0A= 5 0008 10607856 l4: mov r6, #0x5678=0A= 6 000c 0078 l5: mov r7, r8=0A= 7 000e 009A l6: mov r9, r10=0A= 8=20=20=20=20=20=20=20=20=20=20=20=20=20=20=09=20=20=20=20=20=20=20=20= =0A= 9=20=20=20=20=20=20=20=20=20=20=20=20=20=20=09=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=0A= =0CDw32 GAS test.asm page 2=0A= =0A= =0A= DEFINED SYMBOLS=0A= test.asm:2 .text:00000000 l1=0A= test.asm:3 .text:00000002 l2=0A= test.asm:4 .text:00000004 l3=0A= test.asm:5 .text:00000008 l4=0A= test.asm:6 .text:0000000c l5=0A= test.asm:7 .text:0000000e l6=0A= =0A= NO UNDEFINED SYMBOLS=0A= ------=_NextPart_000_0006_01C26645.75553450 Content-Type: application/octet-stream; name="test.dmp" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="test.dmp" Content-length: 529 =0A= a.out: file format elf32-dw32=0A= =0A= Disassembly of section .text:=0A= =0A= 00000000 :=0A= 0: 00 12 mov r1,r2=0A= =0A= 00000002 :=0A= 2: 00 34 mov r3,r4=0A= =0A= 00000004 :=0A= 4: 10 50 mov r5,#0x0=0A= 6: 34 12 *unknown*=0A= =0A= 00000008 :=0A= 8: 10 60 mov r6,#0x0=0A= a: 78 56 *unknown*=0A= =0A= 0000000c :=0A= c: 00 78 mov r7,r8=0A= =0A= 0000000e :=0A= e: 00 9a mov r9,r10=0A= Disassembly of section .data:=0A= ------=_NextPart_000_0006_01C26645.75553450 Content-Type: application/octet-stream; name="test.dmp32" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="test.dmp32" Content-length: 463 =0A= a.out: file format elf32-dw32=0A= =0A= Disassembly of section .text:=0A= =0A= 00000000 :=0A= 0: 00 12 00 34 mov r1,r2=0A= =0A= 00000002 :=0A= 2: 00 34 10 50 mov r3,r4=0A= =0A= 00000004 :=0A= 4: 10 50 34 12 mov r5,#0x0=0A= =0A= 00000008 :=0A= 8: 10 60 78 56 mov r6,#0x0=0A= =0A= 0000000c :=0A= c: 00 78 00 9a mov r7,r8=0A= =0A= 0000000e :=0A= e: 00 9a 00 00 mov r9,r10=0A= Disassembly of section .data:=0A= ------=_NextPart_000_0006_01C26645.75553450--