From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24337 invoked by alias); 5 Dec 2003 02:16:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 24265 invoked from network); 5 Dec 2003 02:16:48 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 5 Dec 2003 02:16:48 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AS5WP-00037M-6U; Thu, 04 Dec 2003 21:16:45 -0500 Date: Fri, 05 Dec 2003 02:16:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [commit/multiarch/hpux] set addr_bits_remove gdbarch method Message-ID: <20031205021645.GB11837@nevyn.them.org> Mail-Followup-To: Joel Brobecker , Andrew Cagney , gdb-patches@sources.redhat.com References: <20030813171916.GB971@gnat.com> <3F3A85FB.5040502@redhat.com> <20031205021321.GM1652@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031205021321.GM1652@gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-12/txt/msg00184.txt.bz2 On Thu, Dec 04, 2003 at 06:13:21PM -0800, Joel Brobecker wrote: > [Coming back to an old thread. Was it that long ago already? Sigh...] > > On Wed, Aug 13, 2003 at 02:39:55PM -0400, Andrew Cagney wrote: > > Yep: Consider merging SMASH_TEXT_ADDRESS with ADDR_BITS_REMOVE > > http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=333 > > > > Any one got a preference over which one goes? Otherwize, Joel, with > > HP/UX cleaned up, it should either way be pretty obvious. > > I looked a bit at the code, and I have a small preference of > ADDR_BITS_REMOVE over SMASH_TEXT_ADDRESS. In addition, the only > 2 targets that set smash_text_address also define addr_bits_remove > (hppa-tdep.c and arm-tdep.c). So it looked like there would be an easy > transition: > > - s/SMASH_TEXT_ADDRESS/ADDR_BITS_REMOVE/g > This should be a noop if we assume: > SMASH_TEXT_ADDRESS <=> ADDR_BITS_REMOVE > > - Remove the two calls to gdb_arch_set_smash_text_address > - Delete the SMASH_TEXT_ADDRESS gdbarch method > > Unfortunately, It doesn't look like these two methods are that > identical, at least in the case of arm: > > static CORE_ADDR > arm_addr_bits_remove (CORE_ADDR val) > { > if (arm_apcs_32) > return (val & (arm_pc_is_thumb (val) ? 0xfffffffe : 0xfffffffc)); > else > return (val & 0x03fffffc); > } > > /* When reading symbols, we need to zap the low bit of the address, > which may be set to 1 for Thumb functions. */ > static CORE_ADDR > arm_smash_text_address (CORE_ADDR val) > { > return val & ~1; > } > > SMASH_TEXT_ADDRESS is used in coffread, dbxread, dwarfread, elfread, > and somread. > > ADDR_BITS_REMOVE is used in arm*.c, buildsym, infrun, monitor, printcmd, > regcache, remote-mips, values.c (I have deliberately excluded mips-tdep, > remote-mips, s390-tdep, and sh64-tdep since these can not be covered > while the arm gdbarch is in effect). > > Looks like the merge is not going to be that obvious... We need to see > if we can merge arm_addr_bits_remove and arm_smash_text_address first... I'd want to hear from an ARM maintainer, but if smash_text_address is really only used for text symbols (functions), then those two are equivalent. !arm_apcs_32 implies APCS-26, which implies that the upper six bits don't have a useful value in symbol addresses anyway. And the second bit is not useful in ARM mode. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer