From: Kevin Buettner <kevinb@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [PATCH RFA] solib.c
Date: Thu, 16 Mar 2000 12:21:00 -0000 [thread overview]
Message-ID: <1000316202058.ZM2781@ocotillo.lan> (raw)
The changes below are motivated by the desire to have correct section
addresses stored in the obj_section structs (for shared objects) found
via the object_files list.
More information regarding this issue may be found at
http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00681.html .
There was also a patch appended to the above message. I hereby
withdraw that patch from consideration.
Note that MAX_SECTIONS has been increased to 30 (from 12). The reason
for this is that 12 was much too small. So how did I arrive at 30? I
counted the number of special sections documented in my (now rather
old) System V ABI book and counted 24. I added on six more for good
measure (to accomodate architecture specific sections.)
* solib.c (symbol_add_stub): Make symbol_file_add() aware of
all section addresses, not just .text.
* symtab.h (MAX_SECTIONS): Increase to 30.
Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.3
diff -u -p -r1.3 solib.c
--- solib.c 2000/03/15 16:55:07 1.3
+++ solib.c 2000/03/16 19:34:40
@@ -1182,12 +1182,37 @@ symbol_add_stub (arg)
{
struct section_addr_info section_addrs;
+ struct section_table *stp;
+ struct cleanup *old_chain;
+ int oidx;
memset (§ion_addrs, 0, sizeof (section_addrs));
section_addrs.text_addr = text_addr;
+ old_chain = make_cleanup (null_cleanup, 0);
+
+ for (stp = so->sections, oidx = 0; stp != so->sections_end; stp++)
+ {
+ if (strcmp (stp->the_bfd_section->name, ".data") == 0)
+ section_addrs.data_addr = stp->addr;
+ else if (strcmp (stp->the_bfd_section->name, ".bss") == 0)
+ section_addrs.bss_addr = stp->addr;
+
+ if (stp->the_bfd_section->flags & (SEC_ALLOC | SEC_LOAD)
+ && oidx < MAX_SECTIONS)
+ {
+ section_addrs.other[oidx].addr = stp->addr;
+ section_addrs.other[oidx].name =
+ xstrdup (stp->the_bfd_section->name);
+ make_cleanup (free, section_addrs.other[oidx].name);
+ section_addrs.other[oidx].sectindex = stp->the_bfd_section->index;
+ oidx++;
+ }
+ }
+
so->objfile = symbol_file_add (so->so_name, so->from_tty,
§ion_addrs, 0, OBJF_SHARED);
+ do_cleanups (old_chain);
}
return (1);
Index: symtab.h
===================================================================
RCS file: /cvs/src/src/gdb/symtab.h,v
retrieving revision 1.3
diff -u -p -r1.3 symtab.h
--- symtab.h 2000/03/14 19:58:02 1.3
+++ symtab.h 2000/03/16 19:34:44
@@ -842,7 +842,7 @@ struct section_offsets
can keep track of the section names until we read the file and
can map them to bfd sections. */
-#define MAX_SECTIONS 12
+#define MAX_SECTIONS 30
struct section_addr_info
{
/* Sections whose names are always known to gdb. */
next reply other threads:[~2000-03-16 12:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-03-16 12:21 Kevin Buettner [this message]
2000-04-01 0:00 ` Jim Blandy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1000316202058.ZM2781@ocotillo.lan \
--to=kevinb@cygnus.com \
--cc=gdb-patches@sourceware.cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox