From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6539 invoked by alias); 27 Jan 2003 18:49:32 -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 6514 invoked from network); 27 Jan 2003 18:49:32 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 172.16.49.205 with SMTP; 27 Jan 2003 18:49:32 -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 NAA26989; Mon, 27 Jan 2003 13:39:53 -0500 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id NAA32190; Mon, 27 Jan 2003 13:49:31 -0500 Message-ID: <101601c2c634$c78ab2f0$0202040a@catdog> From: "Kris Warkentin" To: "Andrew Cagney" Cc: , References: <0eba01c2c32b$aedcef40$0202040a@catdog> <3E356A0E.5080902@redhat.com> Subject: Re: Adding QNX core-file support to bfd Date: Mon, 27 Jan 2003 18:49: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/msg00437.txt.bz2 > > Right now, we have a special elfcore_grok_qnx_note() function that is called > > in elf.c in much the same way as elfcore_grok_netbsd_note() is called (check > > the namedata for a string and call the function if it matches). > > It looks like a dispatch table is needed so that both the QNX and can > have their support conditionally linked in. This would be a good idea. All we need to do is check if the namedata is "QNX" (NetBSD looks for "NetBSD-CORE"). Perhaps something like: if( elfcore_grok_special_note && core_namedata_str && strncmp(in.namedata, core_namedata_str, strlen(core_namedata_str)) == 0){ if(!elfcore_grok_special_note(abfd, &in)) goto error; } Then a target just initializes elfcore_grok_special_note and core_namedata_str and all it's other functionality can be in a separate object. > > 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. > > What exactly is this support code? Keep in mind that all of the support > functions et.al. will need to be included in a GDB distribution. It's just code to decode our registers and notes from our core-file. We just make pseudosections in the bfd so that our gdb stuff can read it out. The only real problem is that it relies on one of our gdb headers. Nick Clifton pointed out that we could just put that header with bfd instead of gdb which solves all our problems. We just put all our 'qnx_grok_this_and_that()' functions and header includes in that object which is conditionally compiled. cheers, Kris