From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18717 invoked by alias); 2 Sep 2002 22:31:01 -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 18710 invoked from network); 2 Sep 2002 22:31:00 -0000 Received: from unknown (HELO dr-evil.shagadelic.org) (208.176.2.174) by sources.redhat.com with SMTP; 2 Sep 2002 22:31:00 -0000 Received: by dr-evil.shagadelic.org (Postfix, from userid 7518) id 6221D9869; Mon, 2 Sep 2002 15:31:00 -0700 (PDT) Date: Mon, 02 Sep 2002 15:31:00 -0000 From: Jason R Thorpe To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] i386-netbsd* configury cleanup Message-ID: <20020902153100.E6992@dr-evil.shagadelic.org> Mail-Followup-To: Jason R Thorpe , Mark Kettenis , gdb-patches@sources.redhat.com References: <20020902102434.H4034@dr-evil.shagadelic.org> <868z2kt6bb.fsf@elgar.kettenis.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <868z2kt6bb.fsf@elgar.kettenis.dyndns.org>; from kettenis@chello.nl on Mon, Sep 02, 2002 at 11:44:40PM +0200 Organization: Wasabi Systems, Inc. X-SW-Source: 2002-09/txt/msg00027.txt.bz2 On Mon, Sep 02, 2002 at 11:44:40PM +0200, Mark Kettenis wrote: > There's a slight problem here: it seems to be impossible to > distinguish an OpenBSD binary from a NetBSD a.out binary. That was > the main reason why I made i386-*-opensbd* identical to i386-netbsd. > As long as you keep the support for older NetBSD's this should work > fine. Unfortunately... Basically nothing that is done for i386-netbsdelf is pertinent to i386-openbsd and I as the NetBSD target maintainer don't want to be stuck in the position of having to worry about a breaking support for a system, which *happens* to be based on an ancient version of NetBSD, which I don't use. In the signal trampoline example, suppose OpenBSD changed the VM layout such that the singal trampoline start/end was different from NetBSD's. If you can't distinguish the NetBSD and OpenBSD a.out binaries, then you're stuck anyway. What really has to happen is for there to be new OSABI numbers assigned for OpenBSD, the default OSABI to be set based on the configured target, and for the OpenBSD configs to not depend on NetBSD-specific code. Sure, OpenBSD has made the bad decision of sticking with an inflexible object format like a.out (no ABI ID tags), and made the bad decision years ago to not change their a.out magic number (it's not like those OpenBSD a.out binaries will run on NetBSD, even though they appear to be NetBSD binaries). However, I don't think it's particularly fair to ask me to deal with the consequences of those bad decisions. -- -- Jason R. Thorpe