From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26502 invoked by alias); 7 Jan 2003 01:03:24 -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 26495 invoked from network); 7 Jan 2003 01:03:23 -0000 Received: from unknown (HELO main.gmane.org) (80.91.224.249) by 209.249.29.67 with SMTP; 7 Jan 2003 01:03:23 -0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18Vi88-0004ko-00 for ; Tue, 07 Jan 2003 02:02:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gdb-patches@sources.redhat.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18Vi88-0004kf-00 for ; Tue, 07 Jan 2003 02:02:08 +0100 Path: not-for-mail From: "Raoul Gough" Subject: Re: coffread.c extension for DLLs without debugging symbols Date: Tue, 07 Jan 2003 01:03:00 -0000 Message-ID: References: <20030104044408.GA7364@redhat.com> <20030104205130.GA9784@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@main.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SW-Source: 2003-01/txt/msg00251.txt.bz2 "Christopher Faylor" wrote in message news:20030104205130.GA9784@redhat.com... > On Sat, Jan 04, 2003 at 04:25:16PM -0000, Raoul Gough wrote: > >"Christopher Faylor" wrote in message > >news:20030104044408.GA7364@redhat.com... [snip] > >>3) objdump -p already has the ability to read and report on the export > >>table. I wonder if it would be useful (or possible) to generalize this > >>code so that gdb and objdump would be using the same base. I haven't > > > >I assumed that since ld did it the hard way, there wasn't any proper > >support for this in bfd - maybe that's not true. Obviously, sharing > >this kind of code between code bases would be the ideal situation, but > >I don't think I've got enough of an overview to do that. > > Hmm. You're right ld does it the hard way doesn't it? Well, I don't > want to saddle you with one of those "The best way to deal with this > is to redesign binutils, gcc, and awk so that it will all be transparent > to gdb" type of deals. If you can find some kind of common ground in > bfd that ld, gdb, and objdump (and who knows, objcopy?) can all use then > that would be a huge win. Otherwise your current plan is fine, IMO. I've looked into the objdump code, and the relevant code in BFD seems to be the function pe_print_edata which seems to originate in peXXigen.c. Unfortunately, this just dumps the info in text form, and doesn't provide any kind of iterator or callback interface. On the other hand, the BFD code looks a lot cleaner than the stuff I got out of ld, so I'm considering copying this code instead. Of course it would be good to share the code, but this kind of thing won't fit into the generic BFD interface. One possibility would be to expose a platform-specific interface from within the BFD internals. Can anyone suggest a BFD maintainer to talk to about this? Regards, Raoul Gough.