Re: [RFC]: win32-nat.c better handling of DLL relocation

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

"Christopher Faylor" <cgf@redhat.com> wrote in message
news:20030111172431.GA5683@redhat.com...
> 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
.data
> >or .bss don't get fixed up properly. This patch fixes the problem
by
> >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
> >avejk1$lv6$1@main.gmane.org, posted 7 Jan 2003 13:10:49 -0000).
This
> >showed that gdb 5.2.1 didn't handle any DLL symbol relocations. The
> >current CVS version only handles the .text section. With this
patch,
> >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
get_relocated_section_addrs.
>
> I took a quick glance.  Looks good.  Now we just need that pesky
> assignment.

Thanks.

>
> <idle musing>I wonder if there is some way to do all of this
assignment stuff
> electronically.  It seems silly that we still have to rely on paper
for this
> 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).

Raoul Gough.