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

"Christopher Faylor" <> wrote in message">
> On Sat, Jan 04, 2003 at 04:25:16PM -0000, Raoul Gough wrote:
> >"Christopher Faylor" <> wrote in message
> >">
> >> P.S.  Assuming that this works as advertised, I assume that you
> >> have no objections to my releasing a new version of gdb for
> >> with this patch in it before the patch makes its way into the
> >> gdb repository, right?  I think there are a few users in the
> >> 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.

Chris, I've done some more testing and discovered a problem with the
virtual memory address determination mechanism. I've been using
bfd_get_section_vma to find out where each section is in memory, but
this is not always correct. BFD returns the DLL's *preferred* load
address, but it may actually have been relocated during loading
because of address space clashes. It seems obvious now, but BFD is not
the right place to get the needed information. I'm looking into the
win32-nat code that handles DLL load events, which *does* know about
the real load address. Unfortunately, this really will make the code
win32 specific. Unless someone else can suggest anything better?

Actually, this seems like a generic bug in GDB's DLL handling - by
compiling with debugging symbols, the problem is even visible without
my patch. Have a look at the attached example, which shows GDB 5.2.1
getting it wrong.

Raoul Gough.

Attachment: example2.txt
Description: Text document

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