From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24034 invoked by alias); 26 Nov 2002 01:04:39 -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 24027 invoked from network); 26 Nov 2002 01:04:38 -0000 Received: from unknown (HELO yeah-baby.shagadelic.org) (208.176.2.162) by sources.redhat.com with SMTP; 26 Nov 2002 01:04:38 -0000 Received: by yeah-baby.shagadelic.org (Postfix, from userid 2158) id 779927DB1; Mon, 25 Nov 2002 17:04:38 -0800 (PST) Date: Mon, 25 Nov 2002 17:04:00 -0000 From: Jason R Thorpe To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: HPPA multiarching plan Message-ID: <20021126010438.GD21009@yeah-baby.shagadelic.org> Mail-Followup-To: Jason R Thorpe , Joel Brobecker , gdb-patches@sources.redhat.com References: <20021126004857.GB23000@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021126004857.GB23000@gnat.com> User-Agent: Mutt/1.4i Organization: Wasabi Systems, Inc. X-SW-Source: 2002-11/txt/msg00627.txt.bz2 On Mon, Nov 25, 2002 at 04:48:57PM -0800, Joel Brobecker wrote: > - Add 2 new OSABI enums: HPPA_HPUX and HPPA64_HPUX. > (it seems important to me to keep the OS name in the enum, to > differentiate with HPPA_LINUX for instance) You should not need the processor name in the OSABI ("embedded ABIs" are kind of a special case, which is why you see the processor name in those). You also should not need the "64" .. I would guess that would be differentiated based on the object file format (SOM [32] vs. Elf32 vs. Elf64 -- assuming hppa64 binaries use the Elf64 format; I'm not sure that they do, please educate me :-). So, I think you only need GDB_OSABI_HPUX. > - The sniffer would then guess the correct value based like so: > > 1. If object format is ELF > -> OSABI = HPPA64_HPUX > > 2. If object format is SOM > -> OSABI = HPPA_HPUX I don't think you actually need a sniffer, either. Take a look at alpha-tdep.c:alpha_gdbarch_init(). It uses the following algorithm: * Lookup osabi. * If osabi is unknown: * If file is ECOFF, assume GDB_OSABI_OSF1. So, I would say that you could use the following algorithm for HPPA: * Lookup osabi. * If osabi is unknown: * If file is SOM or ELF, assume GDB_OSABI_HPUX. You should also add an HPUX case to osabi.c:generic_elf_osabi_sniffer(), since there is an ELFOSABI constant for HPUX. I think between the change to generic_elf_osabi_sniffer(), and the proper smarts in your hppa_gdbarch_init() function, you can avoid having to add an osabi sniffer. > Later on, when we want to add support for hppa-linux, the sniffer will > need to be refined. I assume hppa-linux uses ELF? In which case we > will probably have to dig into the ELF header to search for the clue > that will reveal either hpux or linux. The existing sniffers will already work with Linux (and eventually hppa-netbsd, as well), since Linux and NetBSD binaries already carry distinguishing markings that are recognized by the existing generic sniffer. -- -- Jason R. Thorpe