This is the mail archive of the
mailing list for the GDB project.
Re: coffread.c extension for DLLs without debugging symbols
On Sat, Jan 04, 2003 at 04:25:16PM -0000, Raoul Gough wrote:
>"Christopher Faylor" <email@example.com> wrote in message
>>On Fri, Jan 03, 2003 at 07:39:31PM -0000, Raoul Gough wrote: 0) The
>>ChangeLog needs more information. Every new function should be
>>mentioned and changes to specific functions should be documented.
>2003-01-03 Raoul Gough <RaoulGough@yahoo.co.uk>
> * coffread.c: Support non-debug export symbols for win32 DLLs.
> (coff_symtab_read): call read_pe_exported_syms iff no symbols
> found and objfile is "pe-i386" or "pei-i386".
> (read_pe_exported_syms): New function.
> (read_pe_section_data): New struct (temporary section info).
> (read_pe_section_index): New function.
> (read_pe_truncate_name): New function.
> (get_section_vmas): New function.
> (add_pe_exported_sym): New function.
> (pe_get16, pe_get32, pe_as32): New functions.
>> 1) AFAICT, the formatting of the code looks great (a rarity for a first
>> timer) except for an odd comment or two which doesn't end in a "." as
>> required for a complete sentence. Yeah, yeah, a total nit but hey we've
>> got standards!
>OK, I've fixed those comments (new diff attached). Note also that I'd
>used strncmp, *and* got the "n" wrong, where I should have used strcmp
Huh. Well, I tried your patch and it worked fine regardless. It's funny
to see actual symbols being reported now rather than random hex addresses
or, worse, some random unrelated symbol plus a large offset.
>>2) I wonder if this code should be ifdef'ed somehow for Windows since
>>it will add extra code for no gain on every COFF platform. Of course,
>>how many of those are there out there? Maybe this isn't a huge issue
>I wondered about that myself. However, wouldn't that suggest putting
>the bulk of the code somewhere like win32-nat.c?
That would be fine with me (especially since I can approve that part of
gdb). So, you'd need some kind of hooks in coffread.c to handle this.
I guess we should wait for the coffread maintainer to offer an opinion
before you go to this effort, though.
>>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.
>> P.S. Assuming that this works as advertised, I assume that you will
>> have no objections to my releasing a new version of gdb for windows
>> with this patch in it before the patch makes its way into the official
>> gdb repository, right? I think there are a few users in the cygwin
>> mailing list that would appreciate this change.
>By all means - please do. You may as well use the new diff for the
>comment fixes and the strncmp business.
Ok. Coming soon to a cygwin mirror near you.
>>Special for spam email harvesters: send email to
>>firstname.lastname@example.org and be permanently blocked from mailing
>>lists at sources.redhat.com.
>Alright! Sock it to 'em, redhat!
Heh. So far the email@example.com mailing list is in the top
fifteen most popular mailing lists at sources.redhat.com. Imagine that.
If anyone is so inclined as to mention firstname.lastname@example.org,
email@example.com, firstname.lastname@example.org, or email@example.com in
their messages to the internet, it would probably help in the war on