From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12187 invoked by alias); 25 Apr 2012 15:57:01 -0000 Received: (qmail 12173 invoked by uid 22791); 25 Apr 2012 15:57:00 -0000 X-SWARE-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Apr 2012 15:56:40 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SN4a8-00047q-AR from Maciej_Rozycki@mentor.com for gdb-patches@sourceware.org; Wed, 25 Apr 2012 08:56:40 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Apr 2012 08:56:39 -0700 Received: from [172.30.0.84] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Wed, 25 Apr 2012 16:56:37 +0100 Date: Wed, 25 Apr 2012 15:57:00 -0000 From: "Maciej W. Rozycki" To: Yao Qi CC: Subject: Re: [PATCH] microMIPS support In-Reply-To: <4F97DFEC.5030007@codesourcery.com> Message-ID: References: <4F97DFEC.5030007@codesourcery.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00867.txt.bz2 On Wed, 25 Apr 2012, Yao Qi wrote: > > +int > > +mips_pc_is_micromips (struct gdbarch *gdbarch, CORE_ADDR memaddr) > > +{ > > + struct minimal_symbol *sym; > > + > > + /* A flag indicating that this is a microMIPS function is stored by > > + elfread.c in the high bit of the info field. Use this to decide > > + if the function is microMIPS. Otherwise if bit 0 of the address > > + is set, then ELF file flags will tell if this is a microMIPS > > + function. */ > > + sym = lookup_minimal_symbol_by_pc (memaddr); > > + if (sym) > > + return msymbol_is_micromips (sym); > > + else > > + return is_micromips_addr (gdbarch, memaddr); > > +} > > Why don't we check `is_micromips_addr' first, and return early if it > returns true? In this way, we can avoid some symbol lookups. The choice of the sequence is deliberate and actually we used to do the checks in the opposite order for MIPS16 code until recently. The reason is there is IMO no point in using the wrong ISA type where the ISA bit has been set incorrectly, e.g. the wrong software breakpoint instruction when someone says: (gdb) break *0xdeadbeef and the address actually refers MIPS32 code. Also the opposite does not work, that is with the current arrangement the ISA bit of the MEMADDR argument may have been implicitly cleared elsewhere even when referencing a piece of compressed code and no numeric address actually used. I think code should behave as consistently as possible, and therefore for all the three ISAs any associated symbol's attribute is checked first, followed by checking the ISA bit specified explicitly in the address. The latter case is only meant to cover addresses for which no symbol information of any kind could have been found. Does it clear your concern? Maciej