From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32050 invoked by alias); 31 Jul 2013 17:24:35 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 32041 invoked by uid 89); 31 Jul 2013 17:24:34 -0000 X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RDNS_NONE,SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO mail-wi0-f181.google.com) (209.85.212.181) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 31 Jul 2013 17:24:33 +0000 Received: by mail-wi0-f181.google.com with SMTP id en1so928540wid.2 for ; Wed, 31 Jul 2013 10:24:25 -0700 (PDT) X-Received: by 10.180.36.212 with SMTP id s20mr5049836wij.13.1375291465498; Wed, 31 Jul 2013 10:24:25 -0700 (PDT) Received: from localhost ([2.26.203.233]) by mx.google.com with ESMTPSA id r6sm3764589wiw.0.2013.07.31.10.24.24 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 31 Jul 2013 10:24:24 -0700 (PDT) From: Richard Sandiford To: "Maciej W. Rozycki" Mail-Followup-To: "Maciej W. Rozycki" ,, rdsandiford@googlemail.com Cc: Subject: Re: Is this "gdb disassembler" code still needed? References: <87d2r83elf.fsf@talisman.default> <878v1w34ms.fsf@talisman.default> Date: Wed, 31 Jul 2013 17:24:00 -0000 In-Reply-To: (Maciej W. Rozycki's message of "Wed, 31 Jul 2013 17:23:56 +0100") Message-ID: <87iozqabi0.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-07/txt/msg00101.txt.bz2 "Maciej W. Rozycki" writes: > On Wed, 26 Jun 2013, Richard Sandiford wrote: > >> > Other than that I am fairly sure the behaviour is intentional, so except >> > from any microMIPS change to match the MIPS16 variant please refrain from >> > fiddling with these bits until I am done with the change proposed here: >> > >> > http://sourceware.org/ml/binutils/2012-05/msg00183.html >> > http://sourceware.org/ml/binutils/2012-06/msg00114.html >> >> OK, thanks. I'll change microMIPS to match MIPS16 like you say. > > What happened to this code after your recent changes? I get rubbish in > disassembly now, e.g.: > > Dump of assembler code for function t1: > 0x00400991 <+0>: save a0-a3,32,ra,s1 > 0x00400995 <+4>: addiu s1,sp,16 > 0x00400997 <+6>: lw v1,0x4009f4 > 0x00400999 <+8>: lw v0,0x4009f0 > 0x0040099b <+10>: move t9,v1 > 0x0040099d <+12>: move t8,v0 > 0x0040099f <+14>: lw v0,24(s1) > 0x004009a1 <+16>: move a1,t9 > 0x004009a3 <+18>: move a0,t8 > 0x004009a5 <+20>: jal 0x400da0 > 0x004009a9 <+24>: nop > [...] Gah, sorry. The code is still there, but I think in the MIPS16 case it's being thwarted by an even base address. Does this fix it? (microMIPS should be OK.) Richard opcodes/ * mips-dis.c (print_mips16_insn_arg): Include ISA bit in base address. Index: opcodes/mips-dis.c =================================================================== --- opcodes/mips-dis.c 2013-07-31 18:16:42.972774949 +0100 +++ opcodes/mips-dis.c 2013-07-31 18:19:37.661036158 +0100 @@ -1565,7 +1565,7 @@ print_mips16_insn_arg (struct disassembl } } - print_insn_arg (info, state, opcode, operand, baseaddr, uval); + print_insn_arg (info, state, opcode, operand, baseaddr + 1, uval); break; } }