This is the mail archive of the
mailing list for the GDB project.
Re: [RFC]: win32-nat.c better handling of DLL relocation
"Christopher Faylor" <email@example.com> wrote in message
> On Sat, Jan 11, 2003 at 03:52:09PM -0000, Raoul Gough wrote:
> >win32-nat.c currently only passes the loaded address of the .text
> >section into symbol_file_add, which means that any symbols from
> >or .bss don't get fixed up properly. This patch fixes the problem
> >calculating the load addresses of all sections known to bfd.
> >I recently posted a test case which demonstrates the relocation
> >problem in the "coffread.c extension" thread (message ID
> >firstname.lastname@example.org, posted 7 Jan 2003 13:10:49 -0000).
> >showed that gdb 5.2.1 didn't handle any DLL symbol relocations. The
> >current CVS version only handles the .text section. With this
> >it handles all sections correctly.
> >Raoul Gough.
> >2003-01-10 Raoul Gough <RaoulGough@yahoo.co.uk>
> > * win32-nat.c(get_relocated_section_addrs): New function. Find
> > section load addresses for symbol handling in relocated DLLs.
> > (solib_symbols_add): Open a bfd and call
> I took a quick glance. Looks good. Now we just need that pesky
> <idle musing>I wonder if there is some way to do all of this
> electronically. It seems silly that we still have to rely on paper
> kind of thing.</idle musing>
Actually, I asked that question myself, and Jessica (the assignment
clerk) explained it all to me. I was wondering why I couldn't at least
*receive* the forms via email and post the signed forms back (saving
the postal delay in one direction). Apparently paper is still the way
to do it, ensuring that nothing has been altered along the way
("integrity of content" was how she put it).