solib.c: solib_extract_address??

[Kevin Buettner]

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).

Kevin