From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14148 invoked by alias); 29 Jan 2003 17:48:04 -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 14123 invoked from network); 29 Jan 2003 17:48:03 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 172.16.49.205 with SMTP; 29 Jan 2003 17:48:03 -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 MAA12825; Wed, 29 Jan 2003 12:38:14 -0500 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id MAA19655; Wed, 29 Jan 2003 12:48:02 -0500 Message-ID: <151901c2c7be$84b2f6f0$0202040a@catdog> From: "Kris Warkentin" To: "Kris Warkentin" , "Andrew Cagney" Cc: , References: <0eba01c2c32b$aedcef40$0202040a@catdog> <3E356A0E.5080902@redhat.com> <101601c2c634$c78ab2f0$0202040a@catdog> Subject: Re: Adding QNX core-file support to bfd Date: Wed, 29 Jan 2003 17:48: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/msg00495.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. I'm having trouble coming up with a nice way to do this. Two problems: 1) Where do I initialize things like this? Conceivably it could be done in the 'core_file_p' function but in our case though, we're just using the generic elf32 stuff. The other problem is that I'm not sure when core_file_p gets called. Our core file support is in elfcore_read_notes() in elf.c. We don't have any special code other than that to recognize a QNX core. 2) How do I deal with the situation when bfd is configured for all targets? What I had thought to do was to set up a list of alternative core-file recognition patterns and the corresponding function hooks and then the target could add its own entries to the list. That way elfcore_read_notes() could just run through the list to see what type of core it has. What about struct elf_backend_data? We could add a special 'grok_note function hook' field which elfcore_grok_note() could check first. It still leaves me with the problem of where to initialize the backend data but I think it might be a cleaner solution. cheers, Kris