coffread.c extension for DLLs without debugging symbols

[Raoul Gough]

"Elena Zannoni" <ezannoni@redhat.com> wrote in message
news:15897.47288.570835.988631@localhost.redhat.com...
> I am including the plain text of the last version of the patch.
> I have noticed a few functions are using K&R style, please use ISO
C.
> Also the formatting for functions should be
>
> int
> foo (int par1, int par2)
>
> so that grep ^foo will work.

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.

>
> (sorry, I have to ask) Do you have a copyright assignment with the
FSF?

No - I don't mind filling one out, though (at least I think I don't -
I haven't seen one yet :-). Can you email me one, please?

>
> 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.

>
> 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?

Regards,
Raoul Gough.

>
> Elena
>
>
> Index: coffread.c
[snip]