This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: solib.c: solib_extract_address??
- To: Michael Snyder <msnyder at redhat dot com>, gdb at sourceware dot cygnus dot com
- Subject: Re: solib.c: solib_extract_address??
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Mon, 23 Oct 2000 10:03:11 -0700
- References: <1001022081417.ZM17309@ocotillo.lan>
On Oct 22, 1:14am, Kevin Buettner wrote:
> Could someone explain SOLIB_EXTRACT_ADDRESS / solib_extract_address() in
> solib.c to me?
>
> Here's the version (w/ annotations) that we currently have in the
> repository.
>
> 1.21 (msnyder 30-Aug-00): /* Function to extract an address from a solib structure.
> 1.3 (jimb 15-Mar-00): When GDB is configured for some 32-bit targets (e.g. Solaris 2.7
> 1.3 (jimb 15-Mar-00): sparc), BFD is configured to handle 64-bit targets, so CORE_ADDR is
> 1.3 (jimb 15-Mar-00): 64 bits. We have to extract only the significant bits of addresses
> 1.21 (msnyder 30-Aug-00): to get the right address when accessing the core file BFD.
> 1.3 (jimb 15-Mar-00):
> 1.21 (msnyder 30-Aug-00): We'll use the BFD itself to determine the number of significant bits.
> 1.21 (msnyder 30-Aug-00): MVS, June 2000 */
> 1.21 (msnyder 30-Aug-00):
> 1.21 (msnyder 30-Aug-00): static CORE_ADDR
> 1.21 (msnyder 30-Aug-00): solib_extract_address (void *memberp)
> 1.21 (msnyder 30-Aug-00): {
> 1.21 (msnyder 30-Aug-00): return extract_address (memberp,
> 1.22 (kevinb 31-Aug-00): bfd_get_arch_size (exec_bfd) / 8);
> 1.21 (msnyder 30-Aug-00): }
> 1.21 (msnyder 30-Aug-00):
> 1.21 (msnyder 30-Aug-00): #define SOLIB_EXTRACT_ADDRESS(MEMBER) \
> 1.21 (msnyder 30-Aug-00): solib_extract_address (&MEMBER)
>
> Hey, one of those lines is mine! (I merely fixed a build error.)
> Okay, here's 1.21 just to be sure...
>
> 1.21 (msnyder 30-Aug-00): /* Function to extract an address from a solib structure.
> 1.3 (jimb 15-Mar-00): When GDB is configured for some 32-bit targets (e.g. Solaris 2.7
> 1.3 (jimb 15-Mar-00): sparc), BFD is configured to handle 64-bit targets, so CORE_ADDR is
> 1.3 (jimb 15-Mar-00): 64 bits. We have to extract only the significant bits of addresses
> 1.21 (msnyder 30-Aug-00): to get the right address when accessing the core file BFD.
> 1.3 (jimb 15-Mar-00):
> 1.21 (msnyder 30-Aug-00): We'll use the BFD itself to determine the number of significant bits.
> 1.21 (msnyder 30-Aug-00): MVS, June 2000 */
> 1.21 (msnyder 30-Aug-00):
> 1.21 (msnyder 30-Aug-00): static CORE_ADDR
> 1.21 (msnyder 30-Aug-00): solib_extract_address (void *memberp)
> 1.21 (msnyder 30-Aug-00): {
> 1.21 (msnyder 30-Aug-00): return extract_address (memberp,
> 1.21 (msnyder 30-Aug-00): bfd_elf_get_arch_size (exec_bfd) / 8);
> 1.21 (msnyder 30-Aug-00): }
> 1.21 (msnyder 30-Aug-00):
> 1.21 (msnyder 30-Aug-00): #define SOLIB_EXTRACT_ADDRESS(MEMBER) \
> 1.21 (msnyder 30-Aug-00): solib_extract_address (&MEMBER)
>
> Now look carefully at the following statement:
>
> return extract_address (memberp, bfd_elf_get_arch_size (exec_bfd) / 8);
>
> How exactly is this supposed to work? It looks to me like we're going to
> be always passing the same size for a give architecture without regard
> to the actual size of the data in question, right? This cannot possibly
> be right!
>
> Anyway, the above code loses for sparc-sun-sunos4.1.4. When I revert
> it to the 1.20 version of things, it works fine on this platform...
>
> 1.3 (jimb 15-Mar-00): /* Macro to extract an address from a solib structure.
> 1.3 (jimb 15-Mar-00): When GDB is configured for some 32-bit targets (e.g. Solaris 2.7
> 1.3 (jimb 15-Mar-00): sparc), BFD is configured to handle 64-bit targets, so CORE_ADDR is
> 1.3 (jimb 15-Mar-00): 64 bits. We have to extract only the significant bits of addresses
> 1.3 (jimb 15-Mar-00): to get the right address when accessing the core file BFD. */
> 1.3 (jimb 15-Mar-00):
> 1.3 (jimb 15-Mar-00): #define SOLIB_EXTRACT_ADDRESS(member) \
> 1.3 (jimb 15-Mar-00): extract_address (&member, sizeof (member))
>
> I think this code either needs to be reverted in the repository or revised
> so that it will do the right thing (whatever that happens to be).
Upon rereading this, I see that I didn't write as clearly as I should've.
Jim B's 1.3 version is what I think the code ought to be reverted to.