From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16566 invoked by alias); 24 Jan 2003 15:08:41 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 16552 invoked from network); 24 Jan 2003 15:08:41 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 172.16.49.205 with SMTP; 24 Jan 2003 15:08:41 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id JAA20943; Fri, 24 Jan 2003 09:59:18 -0500 Received: from dash ([192.168.20.32]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id KAA01055; Fri, 24 Jan 2003 10:08:40 -0500 Message-ID: <004f01c2c3ba$ae2726d0$2a00a8c0@dash> From: "Kris Warkentin" To: "Nick Clifton" Cc: , References: <0eba01c2c32b$aedcef40$0202040a@catdog> Subject: Re: Adding QNX core-file support to bfd Date: Fri, 24 Jan 2003 15:08:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SW-Source: 2003-01/txt/msg00413.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. Okay. That's good to know. What I can do to make it a little nicer is to just put the bare minimum into elf.c and then split our other support functions out into separate file that will only be compiled for our target. Second question. The header file that it requires (nto_debug.h) used to be in the top level include directory but it seemed to me that any nto specific includes should be in an 'nto-share' directory in the gdb heirarchy. Unfortunately, binutils doesn't rely on gdb being present so I'm thinking that it might need to be in the 'include' dir. Is there some other way to do this? It doesn't look like the include dir is overly cluttered and I might find some resistance since there aren't really any target specific headers there. Perhaps if I just take the definitions I need and put them into the nto specific file I mentioned earlier? Kris