Re: coffread.c extension for DLLs without debugging symbols

["Raoul Gough" <RaoulGough@yahoo.co.uk>]

"Christopher Faylor" <cgf@redhat.com> wrote in message
news:20030104205130.GA9784@redhat.com...
> On Sat, Jan 04, 2003 at 04:25:16PM -0000, Raoul Gough wrote:
> >"Christopher Faylor" <cgf@redhat.com> 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.