From: Jim Blandy <jimb@zwingli.cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: RFA: Do solib address arithmetic with appropriate truncation
Date: Sat, 02 Feb 2002 17:29:00 -0000 [thread overview]
Message-ID: <20020203013131.C26295E9DE@zwingli.cygnus.com> (raw)
Sat Feb 2 17:03:26 2002 Jim Blandy <jimb@seadog.cygnus.com>
* solib-svr4.c (svr4_truncate_ptr): New function.
(svr4_relocate_section_addresses): Do the address arithmetic with
the appropriate truncation for target addresses, even when
CORE_ADDR is larger than a target address.
Index: gdb/solib-svr4.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/solib-svr4.c,v
retrieving revision 1.20
diff -c -r1.20 solib-svr4.c
*** gdb/solib-svr4.c 2001/11/01 21:05:46 1.20
--- gdb/solib-svr4.c 2002/02/03 01:03:04
***************
*** 1228,1240 ****
xfree (so->lm_info);
}
static void
svr4_relocate_section_addresses (struct so_list *so,
struct section_table *sec)
{
! sec->addr += LM_ADDR (so);
! sec->endaddr += LM_ADDR (so);
}
/* Fetch a link_map_offsets structure for native targets using struct
definitions from link.h. See solib-legacy.c for the function
--- 1228,1259 ----
xfree (so->lm_info);
}
+
+ /* Clear any bits of ADDR that wouldn't fit in a target-format
+ data pointer. "Data pointer" here refers to whatever sort of
+ address the dynamic linker uses to manage its sections. At the
+ moment, we don't support shared libraries on any processors where
+ code and data pointers are different sizes. */
+ static CORE_ADDR
+ svr4_truncate_ptr (CORE_ADDR addr)
+ {
+ if (TARGET_PTR_BIT == sizeof (CORE_ADDR) * 8)
+ /* We don't need to truncate anything, and the bit twiddling below
+ will fail due to overflow problems. */
+ return addr;
+ else
+ return addr & (((CORE_ADDR) 1 << TARGET_PTR_BIT) - 1);
+ }
+
+
static void
svr4_relocate_section_addresses (struct so_list *so,
struct section_table *sec)
{
! sec->addr = svr4_truncate_ptr (sec->addr + LM_ADDR (so));
! sec->endaddr = svr4_truncate_ptr (sec->endaddr + LM_ADDR (so));
}
+
/* Fetch a link_map_offsets structure for native targets using struct
definitions from link.h. See solib-legacy.c for the function
next reply other threads:[~2002-02-03 1:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-02 17:29 Jim Blandy [this message]
2002-02-03 10:24 ` Andrew Cagney
2002-02-04 8:15 ` Kevin Buettner
2002-02-04 9:01 ` Andrew Cagney
2002-02-05 16:07 ` Jim Blandy
2002-02-05 16:39 ` Andrew Cagney
2002-02-06 11:27 ` Jim Blandy
2002-02-06 11:41 ` Andrew Cagney
2002-02-06 14:12 ` Daniel Jacobowitz
2002-02-03 23:09 ` Kevin Buettner
2002-02-05 15:30 ` 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=20020203013131.C26295E9DE@zwingli.cygnus.com \
--to=jimb@zwingli.cygnus.com \
--cc=gdb-patches@sources.redhat.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