From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5921 invoked by alias); 26 Nov 2002 15:26:52 -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 5911 invoked from network); 26 Nov 2002 15:26:48 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 26 Nov 2002 15:26:48 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4A0983F30; Tue, 26 Nov 2002 10:26:43 -0500 (EST) Message-ID: <3DE392B3.70205@redhat.com> Date: Tue, 26 Nov 2002 07:26:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason R Thorpe , Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: HPPA multiarching plan References: <20021126004857.GB23000@gnat.com> <20021126010438.GD21009@yeah-baby.shagadelic.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00646.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. Assuming that HPPA64 and HPPA are different ABIs (true?), then they should be identified using separate OSABI designations. That way, the ABI code is independant of the underlying object file format (ELF or SOM or ....). This is more in line with MIPS with n32, o32, o64 and 64. Andrew