From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32224 invoked by alias); 26 Nov 2002 01:24:56 -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 32217 invoked from network); 26 Nov 2002 01:24:55 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 26 Nov 2002 01:24:55 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id EC314D2CE5; Mon, 25 Nov 2002 17:24:54 -0800 (PST) Date: Mon, 25 Nov 2002 17:24:00 -0000 From: Joel Brobecker To: Jason R Thorpe , gdb-patches@sources.redhat.com Subject: Re: HPPA multiarching plan Message-ID: <20021126012454.GI1259@gnat.com> References: <20021126004857.GB23000@gnat.com> <20021126010438.GD21009@yeah-baby.shagadelic.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021126010438.GD21009@yeah-baby.shagadelic.org> User-Agent: Mutt/1.4i X-SW-Source: 2002-11/txt/msg00629.txt.bz2 My many thanks to Daniel and Jason for their very prompt and helpful answers! > 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 :-). I see what you mean. (and yes, hppa64 uses Elf64). > So, I think you only need GDB_OSABI_HPUX. Ok. > 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. That's absolutely brillant. I'll learn a bit more about this generic sniffer, it looks really cool :). > You should also add an HPUX case to osabi.c:generic_elf_osabi_sniffer(), > since there is an ELFOSABI constant for HPUX. Wildo, thanks for pointing this. 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 Otherwise, what I could do is maintain a local variable in the gdbarch_init routine, and set it depending on the object format... -- Joel