From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28898 invoked by alias); 14 Aug 2003 02:01:40 -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 28371 invoked from network); 14 Aug 2003 02:01:37 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 14 Aug 2003 02:01:37 -0000 Received: from drow by nevyn.them.org with local (Exim 4.20 #1 (Debian)) id 19n7Qj-0006tK-HZ for ; Wed, 13 Aug 2003 22:01:33 -0400 Date: Thu, 14 Aug 2003 02:01:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [commit/RFC/multiarch/hpux] HPUX_ELF osabi init routine incorrectly registered Message-ID: <20030814020133.GA26416@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20030814003222.GK971@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030814003222.GK971@gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-08/txt/msg00232.txt.bz2 On Wed, Aug 13, 2003 at 05:32:22PM -0700, Joel Brobecker wrote: > Hello, > > I noticed while working on the hppa64 target that the HPUX_ELF gdbarch > initialization routine was not called during the gdbarch initialization. > It turns out that we where using the default bfd arch_info descriptor > which corresponds to a 32bit ABI. So when we checked the compatibility > between the arch_info that we registered and the arch_info determined by > the sniffer, we determined that they do not match, and therefore did not > call the assiocated initialization routine. > > I fixed the problem the best way I can, by using a hard-coded number > corresponding to the arch_info that corresponds to hppa2.0w. I don't > know BFD too well yet, but it looks like we should really be defining > new #defines in archures.c for each hppa machine numbers, and then use > them here instead of my hard-coded value. I added a FIXME to remind us, > and will send a patch to binutils shortly. In them meantime, this fixes > the problem. > > Any opinions, maybe? Seems right to me, on all counts. But would you mind sending the BFD patch first and then using the machine #define in GDB? It's just a matter of adding the define and regenerating bfd-in2.h. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer