From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14367 invoked by alias); 26 Nov 2002 01:47:15 -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 14359 invoked from network); 26 Nov 2002 01:47:14 -0000 Received: from unknown (HELO yeah-baby.shagadelic.org) (208.176.2.162) by sources.redhat.com with SMTP; 26 Nov 2002 01:47:14 -0000 Received: by yeah-baby.shagadelic.org (Postfix, from userid 2158) id BBCC67DB1; Mon, 25 Nov 2002 17:47:13 -0800 (PST) Date: Mon, 25 Nov 2002 17:47:00 -0000 From: Jason R Thorpe To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: HPPA multiarching plan Message-ID: <20021126014713.GC21494@yeah-baby.shagadelic.org> Mail-Followup-To: Jason R Thorpe , Joel Brobecker , gdb-patches@sources.redhat.com References: <20021126004857.GB23000@gnat.com> <20021126010438.GD21009@yeah-baby.shagadelic.org> <20021126012454.GI1259@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021126012454.GI1259@gnat.com> User-Agent: Mutt/1.4i Organization: Wasabi Systems, Inc. X-SW-Source: 2002-11/txt/msg00631.txt.bz2 On Mon, Nov 25, 2002 at 05:24:54PM -0800, Joel Brobecker wrote: > My many thanks to Daniel and Jason for their very prompt and helpful > answers! We're glad to help :-) > One little thing that still bothers (because I don't know yet how to > properly handle this) is: some of the gdbarch methods will be different > depending whether it is a pa64 or a pa32... Having 2 osabis was > convenient that way. I see we have NETBSD_AOUT and NETBSD_ELF, perhaps > it would still make sense to define 2 new osabis vis: > - _HPUX_ELF > - _HPUX_SOM Actually, yah, having an HPUX_ELF and and HPUX_SOM probably makes sense, because e.g. shared library handling will be different. (i.e. you would want different osabi_init routines for each format, each of which possibly calling a common one to do some common HPUX setup.) > Otherwise, what I could do is maintain a local variable in the > gdbarch_init routine, and set it depending on the object format... Well.. for things which are purely "pa32 vs pa64" and having nothing to do with the osabi per se, then you can determine this from info in the BFD structure. For things which are osabi-specific, the osabi_init routine for that osabi will fill in the bits of the gdbarch/gdbarch_tdep structures. Take a look at e.g. alphanbsd-tdep.c:alphanbsd_init_abi() (the osabi init routine for Alpha with GDB_OSABI_NETBSD_ELF) and alphanbsd-tdep.c:_initialize_alphanbsd_tdep() (which registers that osabi init routine). BTW, one thing that you're going to run into while doing this is that the shared library support in GDB isn't really multarch'd. That will have to be addressed in order for you to build a GDB which supports both hppa+SOM and hppa64+Elf64. -- -- Jason R. Thorpe