This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: coffread.c extension for DLLs without debugging symbols

Raoul Gough writes:
 > "Elena Zannoni" <> wrote in message
 > > 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?

done, i think.

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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]