* [RFC]: win32-nat.c better handling of DLL relocation
@ 2003-01-11 15:51 Raoul Gough
2003-01-11 17:23 ` Christopher Faylor
0 siblings, 1 reply; 7+ messages in thread
From: Raoul Gough @ 2003-01-11 15:51 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]
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.
[-- Attachment #2: ChangeLog_entry.txt --]
[-- Type: text/plain, Size: 255 bytes --]
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.
[-- Attachment #3: win32-nat.c.diff --]
[-- Type: application/octet-stream, Size: 4401 bytes --]
Index: win32-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/win32-nat.c,v
retrieving revision 1.66
diff -c -p -r1.66 win32-nat.c
*** win32-nat.c 23 Nov 2002 02:49:45 -0000 1.66
--- win32-nat.c 11 Jan 2003 15:49:38 -0000
*************** child_clear_solibs (void)
*** 750,761 ****
solib_end = &solib_start;
max_dll_name_len = sizeof ("DLL Name") - 1;
}
/* Add DLL symbol information. */
static struct objfile *
solib_symbols_add (char *name, int from_tty, CORE_ADDR load_addr)
{
! struct section_addr_info section_addrs;
/* The symbols in a dll are offset by 0x1000, which is the
the offset from 0 of the first byte in an image - because
--- 750,816 ----
solib_end = &solib_start;
max_dll_name_len = sizeof ("DLL Name") - 1;
}
+ \f
+ /* Get the loaded address of all sections, given that .text was loaded
+ at text_load. Assumes that all sections are subject to the same
+ relocation offset. Returns NULL if problems occur or if the
+ sections were not relocated. */
+ static struct section_addr_info *
+ get_relocated_section_addrs (bfd *abfd, CORE_ADDR text_load)
+ {
+ struct section_addr_info *result = NULL;
+ int section_count = bfd_count_sections (abfd);
+ asection *text_section = bfd_get_section_by_name (abfd, ".text");
+ CORE_ADDR text_vma;
+
+ if (!text_section)
+ {
+ /* Couldn't get the .text section. Weird. */
+ }
+
+ else if (text_load == (text_vma = bfd_get_section_vma (abfd, text_section)))
+ {
+ /* DLL wasn't relocated. */
+ }
+
+ else
+ {
+ /* Figure out all sections' loaded addresses. The offset here is
+ such that taking a bfd_get_section_vma() result and adding
+ offset will give the real load address of the section. */
+
+ CORE_ADDR offset = text_load - text_vma;
+
+ struct section_table *table_start = NULL;
+ struct section_table *table_end = NULL;
+ struct section_table *iter = NULL;
+
+ build_section_table (abfd, &table_start, &table_end);
+
+ for (iter = table_start; iter < table_end; ++iter)
+ {
+ /* Relocated addresses. */
+ iter->addr += offset;
+ iter->endaddr += offset;
+ }
+
+ result = build_section_addr_info_from_section_table (table_start,
+ table_end);
+
+ xfree (table_start);
+ }
+
+ return result;
+ }
+ \f
/* Add DLL symbol information. */
static struct objfile *
solib_symbols_add (char *name, int from_tty, CORE_ADDR load_addr)
{
! struct section_addr_info *section_addrs_ptr = NULL;
! static struct objfile *result = NULL;
! bfd *abfd = NULL;
/* The symbols in a dll are offset by 0x1000, which is the
the offset from 0 of the first byte in an image - because
*************** solib_symbols_add (char *name, int from_
*** 764,773 ****
if (!name || !name[0])
return NULL;
! memset (§ion_addrs, 0, sizeof (section_addrs));
! section_addrs.other[0].name = ".text";
! section_addrs.other[0].addr = load_addr;
! return safe_symbol_file_add (name, from_tty, §ion_addrs, 0, OBJF_SHARED);
}
/* Load DLL symbol info. */
--- 819,864 ----
if (!name || !name[0])
return NULL;
! abfd = bfd_openr (name, "pei-i386");
!
! if (!abfd)
! {
! /* pei failed - try pe */
! abfd = bfd_openr (name, "pe-i386");
! }
!
! if (abfd)
! {
! if (bfd_check_format (abfd, bfd_object))
! {
! section_addrs_ptr = get_relocated_section_addrs (abfd, load_addr);
! }
!
! bfd_close (abfd);
! }
!
! if (section_addrs_ptr)
! {
! result = safe_symbol_file_add (name, from_tty, section_addrs_ptr,
! 0, OBJF_SHARED);
!
! free_section_addr_info (section_addrs_ptr);
! }
!
! else
! {
! /* Fallback on handling just the .text section. */
! struct section_addr_info section_addrs;
!
! memset (§ion_addrs, 0, sizeof (section_addrs));
! section_addrs.other[0].name = ".text";
! section_addrs.other[0].addr = load_addr;
!
! result = safe_symbol_file_add (name, from_tty, §ion_addrs,
! 0, OBJF_SHARED);
! }
!
! return result;
}
/* Load DLL symbol info. */
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [RFC]: win32-nat.c better handling of DLL relocation
2003-01-11 15:51 [RFC]: win32-nat.c better handling of DLL relocation Raoul Gough
@ 2003-01-11 17:23 ` Christopher Faylor
2003-01-11 18:18 ` Raoul Gough
2003-01-29 15:20 ` Christopher Faylor
0 siblings, 2 replies; 7+ messages in thread
From: Christopher Faylor @ 2003-01-11 17:23 UTC (permalink / raw)
To: gdb-patches
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.
<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>
cgf
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC]: win32-nat.c better handling of DLL relocation
2003-01-11 17:23 ` Christopher Faylor
@ 2003-01-11 18:18 ` Raoul Gough
2003-01-29 15:20 ` Christopher Faylor
1 sibling, 0 replies; 7+ messages in thread
From: Raoul Gough @ 2003-01-11 18:18 UTC (permalink / raw)
To: gdb-patches
"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.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [RFC]: win32-nat.c better handling of DLL relocation
2003-01-11 17:23 ` Christopher Faylor
2003-01-11 18:18 ` Raoul Gough
@ 2003-01-29 15:20 ` Christopher Faylor
2003-01-29 18:26 ` Raoul Gough
2003-02-06 19:31 ` Raoul Gough
1 sibling, 2 replies; 7+ messages in thread
From: Christopher Faylor @ 2003-01-29 15:20 UTC (permalink / raw)
To: gdb-patches; +Cc: RaoulGough
On Sat, Jan 11, 2003 at 12:24:31PM -0500, Christopher Faylor wrote:
>On Sat, Jan 11, 2003 at 03:52:09PM -0000, Raoul Gough wrote:
>>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.
>
><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>
Any word on the assignment front?
cgf
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC]: win32-nat.c better handling of DLL relocation
2003-01-29 15:20 ` Christopher Faylor
@ 2003-01-29 18:26 ` Raoul Gough
2003-02-06 19:31 ` Raoul Gough
1 sibling, 0 replies; 7+ messages in thread
From: Raoul Gough @ 2003-01-29 18:26 UTC (permalink / raw)
To: gdb-patches; +Cc: Christopher Faylor
"Christopher Faylor" <cgf@redhat.com> wrote in message
news:20030129152104.GD9107@redhat.com...
> On Sat, Jan 11, 2003 at 12:24:31PM -0500, Christopher Faylor wrote:
> >On Sat, Jan 11, 2003 at 03:52:09PM -0000, Raoul Gough wrote:
> >>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.
> >
> ><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>
>
> Any word on the assignment front?
The signed assignment forms are currently on their way back to the FSF
in the post. I was concerned about the extent of the first contracts,
and ended up having to get alternate forms sent out. The new forms
have a specified time period for me to make contributions, covering
two years starting from 1 January 2003. I figure that reduces the risk
of "changes and enhancements to the Program" becoming a legal
nightmare for me twenty years from now.
I guess the forms should be arriving back at the FSF in a couple of
days.
Regards,
Raoul Gough.
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC]: win32-nat.c better handling of DLL relocation
2003-01-29 15:20 ` Christopher Faylor
2003-01-29 18:26 ` Raoul Gough
@ 2003-02-06 19:31 ` Raoul Gough
2003-02-06 19:51 ` Christopher Faylor
1 sibling, 1 reply; 7+ messages in thread
From: Raoul Gough @ 2003-02-06 19:31 UTC (permalink / raw)
To: gdb-patches; +Cc: Christopher Faylor
[-- Attachment #1: Type: text/plain, Size: 415 bytes --]
"Christopher Faylor" <cgf@redhat.com> wrote in message
news:20030129152104.GD9107@redhat.com...
[snip]
> Any word on the assignment front?
I've just received word that my assignment forms have been accepted at
the FSF. I've attached an up-to-date diff for win32-nat.c (against CVS
version 1.69) to this message, and will probably also re-post my
extensions to coffread.c, etc., to the list.
Regards,
Raoul Gough.
[-- Attachment #2: win32-nat.diff.txt --]
[-- Type: text/plain, Size: 4400 bytes --]
Index: win32-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/win32-nat.c,v
retrieving revision 1.69
diff -c -p -r1.69 win32-nat.c
*** win32-nat.c 30 Jan 2003 01:39:52 -0000 1.69
--- win32-nat.c 5 Feb 2003 22:17:55 -0000
*************** child_clear_solibs (void)
*** 749,760 ****
solib_end = &solib_start;
max_dll_name_len = sizeof ("DLL Name") - 1;
}
/* Add DLL symbol information. */
static struct objfile *
solib_symbols_add (char *name, int from_tty, CORE_ADDR load_addr)
{
! struct section_addr_info section_addrs;
/* The symbols in a dll are offset by 0x1000, which is the
the offset from 0 of the first byte in an image - because
--- 749,815 ----
solib_end = &solib_start;
max_dll_name_len = sizeof ("DLL Name") - 1;
}
+ \f
+ /* Get the loaded address of all sections, given that .text was loaded
+ at text_load. Assumes that all sections are subject to the same
+ relocation offset. Returns NULL if problems occur or if the
+ sections were not relocated. */
+ static struct section_addr_info *
+ get_relocated_section_addrs (bfd *abfd, CORE_ADDR text_load)
+ {
+ struct section_addr_info *result = NULL;
+ int section_count = bfd_count_sections (abfd);
+ asection *text_section = bfd_get_section_by_name (abfd, ".text");
+ CORE_ADDR text_vma;
+
+ if (!text_section)
+ {
+ /* Couldn't get the .text section. Weird. */
+ }
+
+ else if (text_load == (text_vma = bfd_get_section_vma (abfd, text_section)))
+ {
+ /* DLL wasn't relocated. */
+ }
+
+ else
+ {
+ /* Figure out all sections' loaded addresses. The offset here is
+ such that taking a bfd_get_section_vma() result and adding
+ offset will give the real load address of the section. */
+
+ CORE_ADDR offset = text_load - text_vma;
+
+ struct section_table *table_start = NULL;
+ struct section_table *table_end = NULL;
+ struct section_table *iter = NULL;
+
+ build_section_table (abfd, &table_start, &table_end);
+
+ for (iter = table_start; iter < table_end; ++iter)
+ {
+ /* Relocated addresses. */
+ iter->addr += offset;
+ iter->endaddr += offset;
+ }
+
+ result = build_section_addr_info_from_section_table (table_start,
+ table_end);
+
+ xfree (table_start);
+ }
+
+ return result;
+ }
+ \f
/* Add DLL symbol information. */
static struct objfile *
solib_symbols_add (char *name, int from_tty, CORE_ADDR load_addr)
{
! struct section_addr_info *section_addrs_ptr = NULL;
! static struct objfile *result = NULL;
! bfd *abfd = NULL;
/* The symbols in a dll are offset by 0x1000, which is the
the offset from 0 of the first byte in an image - because
*************** solib_symbols_add (char *name, int from_
*** 763,772 ****
if (!name || !name[0])
return NULL;
! memset (§ion_addrs, 0, sizeof (section_addrs));
! section_addrs.other[0].name = ".text";
! section_addrs.other[0].addr = load_addr;
! return safe_symbol_file_add (name, from_tty, §ion_addrs, 0, OBJF_SHARED);
}
/* Load DLL symbol info. */
--- 818,863 ----
if (!name || !name[0])
return NULL;
! abfd = bfd_openr (name, "pei-i386");
!
! if (!abfd)
! {
! /* pei failed - try pe */
! abfd = bfd_openr (name, "pe-i386");
! }
!
! if (abfd)
! {
! if (bfd_check_format (abfd, bfd_object))
! {
! section_addrs_ptr = get_relocated_section_addrs (abfd, load_addr);
! }
!
! bfd_close (abfd);
! }
!
! if (section_addrs_ptr)
! {
! result = safe_symbol_file_add (name, from_tty, section_addrs_ptr,
! 0, OBJF_SHARED);
!
! free_section_addr_info (section_addrs_ptr);
! }
!
! else
! {
! /* Fallback on handling just the .text section. */
! struct section_addr_info section_addrs;
!
! memset (§ion_addrs, 0, sizeof (section_addrs));
! section_addrs.other[0].name = ".text";
! section_addrs.other[0].addr = load_addr;
!
! result = safe_symbol_file_add (name, from_tty, §ion_addrs,
! 0, OBJF_SHARED);
! }
!
! return result;
}
/* Load DLL symbol info. */
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [RFC]: win32-nat.c better handling of DLL relocation
2003-02-06 19:31 ` Raoul Gough
@ 2003-02-06 19:51 ` Christopher Faylor
0 siblings, 0 replies; 7+ messages in thread
From: Christopher Faylor @ 2003-02-06 19:51 UTC (permalink / raw)
To: Raoul Gough; +Cc: gdb-patches
On Thu, Feb 06, 2003 at 07:30:21PM -0000, Raoul Gough wrote:
>"Christopher Faylor" <cgf@redhat.com> wrote in message
>news:20030129152104.GD9107@redhat.com...
>[snip]
>> Any word on the assignment front?
>
>I've just received word that my assignment forms have been accepted at
>the FSF. I've attached an up-to-date diff for win32-nat.c (against CVS
>version 1.69) to this message, and will probably also re-post my
>extensions to coffread.c, etc., to the list.
Patch committed.
Thank you!
cgf
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2003-02-06 19:51 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-11 15:51 [RFC]: win32-nat.c better handling of DLL relocation Raoul Gough
2003-01-11 17:23 ` Christopher Faylor
2003-01-11 18:18 ` Raoul Gough
2003-01-29 15:20 ` Christopher Faylor
2003-01-29 18:26 ` Raoul Gough
2003-02-06 19:31 ` Raoul Gough
2003-02-06 19:51 ` Christopher Faylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox