From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-12096-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 17593 invoked by alias); 24 Jan 2003 08:51:39 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 17579 invoked from network); 24 Jan 2003 08:51:38 -0000
Received: from unknown (HELO mx1.redhat.com) (172.16.49.200)
  by 172.16.49.205 with SMTP; 24 Jan 2003 08:51:38 -0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h0O8Mef00921;
	Fri, 24 Jan 2003 03:22:40 -0500
Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h0O8pca00614;
	Fri, 24 Jan 2003 03:51:38 -0500
Received: from north-pole.nickc.cambridge.redhat.com.redhat.com (vpn50-18.rdu.redhat.com [172.16.50.18])
	by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h0O8pZt25702;
	Fri, 24 Jan 2003 03:51:36 -0500
To: "Kris Warkentin" <kewarken@qnx.com>
Cc: <binutils@sources.redhat.com>, <gdb@sources.redhat.com>
Subject: Re: Adding QNX core-file support to bfd
References: <0eba01c2c32b$aedcef40$0202040a@catdog>
From: Nick Clifton <nickc@redhat.com>
Date: Fri, 24 Jan 2003 08:51:00 -0000
In-Reply-To: <0eba01c2c32b$aedcef40$0202040a@catdog>
Message-ID: <m3u1fz2ali.fsf@north-pole.nickc.cambridge.redhat.com>
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2003-01/txt/msg00411.txt.bz2

Hi Kris,

> The problem with this is that all of that code and the support functions for
> reading our registers, status, etc. is wrapped in #ifdef __QNXTARGET__ which
> is defined at configure time.  I believe that this is the sort of clutter
> that you want to avoid but unfortunately, we rely on some of our definitions
> and structures to extract the corefile information.

Using a target specific define does appear to be the way that all core
file types are supported by the bfd library, so you are not doing
anything unusual or unwarranted.  Since the header files that allow
the core file to be decoded are only available on certain targets, it
makes sense that the inclusion of that particular core file support be
dependent upon the host/build environment, and this environment is
determined at configure time.

Cheers
        Nick