From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Received: (qmail 14110 invoked from network); 10 Jan 2003 22:45:48 -0000 Received: from unknown (HELO main.gmane.org) (80.91.224.249) by 209.249.29.67 with SMTP; 10 Jan 2003 22:45:48 -0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18X7t4-0006yT-00 for ; Fri, 10 Jan 2003 23:44:26 +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 18X7t3-0006yK-00 for ; Fri, 10 Jan 2003 23:44:25 +0100 Path: not-for-mail From: "Raoul Gough" Subject: Re: coffread.c extension for DLLs without debugging symbols Date: Fri, 10 Jan 2003 22:45:00 -0000 Message-ID: References: <2110-Sat04Jan2003130101+0200-eliz@is.elta.co.il><15897.47288.570835.988631@localhost.redhat.com> <15898.13355.611979.991969@localhost.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/msg00430.txt.bz2 "Elena Zannoni" wrote in message news:15898.13355.611979.991969@localhost.redhat.com... > Raoul Gough writes: > > OK, this is no problem. In fact the K&R style functions are straight > > out of pe-dll.c from ld, and I think there are existing bfd_ functions > > that do the same thing. I'll fix the code to use the bfd functions > > (removing the K&R style functions) and also sort out the other > > formatting issues as well. > > > thanks Actually, I've left those functions in after all, but reformatted them. Turns out that the bfd_ functions are different enough that I didn't want to try the change (if it's not broken....). [snip] > > > As far as the new code being triggered, could you do it based on the > > > existance of some particular section/data in the objfile? I see > > that > > > you bail out of read_pe_exported_syms if there are no exports, could > > > something on the same flavour be done? (like using bfd_get_flavour, > > > or bfd_get_section_by_name, etc) > > > > Not sure what you mean here - it currently uses both the pe_file flag > > and bfd_get_target() to check whether to proceed with the processing. > > I could also add a get_section_by_name(".edata") I guess. > > > > Usually gdb triggers reading one debug format or another depending on > the presence of certain sections names. So here, instead of looking at > the target you can look at the existance of .edata. > > Look at elfread.c and how it finds which debug format is used. It is > not using get_section_by_name(), but the idea is similar. I've decided to stick with the bfd_get_target, because I'd like to make sure that the code only attempts to process i386 PE files (it might work on, say, Alpha, but I can't test it). I'm sure there are other ways to check this, but coffread.c already uses the target name to set up the pe_file flag. Note also that the .edata section can be empty (seems to happen with .exe files). > > > > > > > About location of the code, add maybe a coff-pe-read.c? (ulgh) But > > > since it deals with reading symbols, I would think it more logical > > to > > > stay in some object/debug format related file rather than in a > > target > > > related file. > > > > I agree - there will still have to be a hook in coffread to call the > > new function, though. Does this also mean changing the config somehow > > to make it compile the new module under the right circumstances? Any > > advice on doing this? > > > > No, I just meant that the functions to manipulate these symbols could > be moved into their own file. Gdb always includes all the > debug/objfile readers in each build, so no need to tweak configure. coff-pe-read it is (see my other posting for the new patches). Regards, Raoul Gough.