RFA: Do solib address arithmetic with appropriate truncation

RFA: Do solib address arithmetic with appropriate truncation

[Jim Blandy]

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

Re: RFA: Do solib address arithmetic with appropriate truncation

[Andrew Cagney]

> + /* 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);
> + }


There must be something around that this code can use.  On something 
like a mips, this would be wrong - remember the sign extension problem.

Andrew

Re: RFA: Do solib address arithmetic with appropriate truncation

[Kevin Buettner]

On Feb 2,  8:31pm, Jim Blandy wrote:

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

I think this is a satisfactory short term (or even mid term) solution.
I think the long term solution will be to introduce a method for adding
offsets to CORE_ADDRs.  See

    http://sources.redhat.com/ml/gdb/2001-10/msg00036.html

I think it's okay to commit this patch, but I'd appreciate it if you'd
add a comment indicating that svr4_truncate_ptr() should be removed
when methods for adding displacements to CORE_ADDRs are introduced.

Kevin

Re: RFA: Do solib address arithmetic with appropriate truncation

[Kevin Buettner]

On Feb 3, 12:37pm, Andrew Cagney wrote:

> > + /* 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);
> > + }
> 
> 
> There must be something around that this code can use.  On something 
> like a mips, this would be wrong - remember the sign extension problem.

I've never really understood the MIPS sign extension problem.  Does it
occur when TARGET_PTR_BIT is smaller than the size of one or more of
the registers used to hold addresses?

Kevin

Re: RFA: Do solib address arithmetic with appropriate truncation

[Andrew Cagney]

> There must be something around that this code can use.  On something 
>> like a mips, this would be wrong - remember the sign extension problem.
> 
> 
> I've never really understood the MIPS sign extension problem.  Does it
> occur when TARGET_PTR_BIT is smaller than the size of one or more of
> the registers used to hold addresses?


The MIPS ISA when running 32 bit code, sign extends pointers.  GDB 
mimics this behavour.  If it encounters a 32 bit pointer it will convert 
it to/from a cannonical form (sign extended CORE_ADDR for MIPS).   Such 
pointers occure everywhere - debug info, registers, memory, ... By 
always sign extending, GDB avoids any potential inconsistency and latent 
bugs.  POINTER_TO_ADDRESS and ADDRESS_TO_POINTER handle this.

When debugging MIPS, the first thing to check is that CORE_ADDRs are 
sign exteded.  A value like ``0x80001234'' as the patch would generate, 
indicate a bug.

Interestingly, the SPARC is showing signs of the same, or similar, problems.

enjoy,
Andrew

Re: RFA: Do solib address arithmetic with appropriate truncation

[Jim Blandy]

Kevin Buettner <kevinb@redhat.com> writes:

> On Feb 2,  8:31pm, Jim Blandy wrote:
> 
> > 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.
> 
> I think this is a satisfactory short term (or even mid term) solution.
> I think the long term solution will be to introduce a method for adding
> offsets to CORE_ADDRs.  See
> 
>     http://sources.redhat.com/ml/gdb/2001-10/msg00036.html
> 
> I think it's okay to commit this patch, but I'd appreciate it if you'd
> add a comment indicating that svr4_truncate_ptr() should be removed
> when methods for adding displacements to CORE_ADDRs are introduced.

Okay, I've committed it with the following comment:

/* 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.

   This isn't really the right solution.  What we really need here is
   a way to do arithmetic on CORE_ADDR values that respects the
   natural pointer/address correspondence.  (For example, on the MIPS,
   converting a 32-bit pointer to a 64-bit CORE_ADDR requires you to
   sign-extend the value.  There, simply truncating the bits above
   TARGET_PTR_BIT, as we do below, is no good.)  This should probably
   be a new gdbarch method or something.  */

Re: RFA: Do solib address arithmetic with appropriate truncation

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> > There must be something around that this code can use.  On something
> >> like a mips, this would be wrong - remember the sign extension problem.
> > I've never really understood the MIPS sign extension problem.  Does
> > it
> > occur when TARGET_PTR_BIT is smaller than the size of one or more of
> > the registers used to hold addresses?
> 
> 
> The MIPS ISA when running 32 bit code, sign extends pointers.  GDB
> mimics this behavour.  If it encounters a 32 bit pointer it will
> convert it to/from a cannonical form (sign extended CORE_ADDR for
> MIPS).   Such pointers occure everywhere - debug info, registers,
> memory, ... By always sign extending, GDB avoids any potential
> inconsistency and latent bugs.  POINTER_TO_ADDRESS and
> ADDRESS_TO_POINTER handle this.
> 
> When debugging MIPS, the first thing to check is that CORE_ADDRs are
> sign exteded.  A value like ``0x80001234'' as the patch would
> generate, indicate a bug.
> 
> Interestingly, the SPARC is showing signs of the same, or similar, problems.

Let me get this straight.  From reading the .so file's section header
table, I'm going to get 64-bit offsets, right?  And from reading the
dynamic linker's table of loaded shared libraries, I'm going to get
32-bit offsets, right?

So, if I have a .so section which says its offset is 0xf0000000, and
the dynamic linker's table says that the .so has been loaded at an
offset of 0x20000000, should I determine that the address at which the
section was actually loaded is 0x110000000, or 0x10000000?

Or, if the section's offset is 0x70000000, and the dynamic linker says
the .so is loaded at an offset of 0x20000000, do I get a section address
of 0xffffffff90000000, or 0x0000000090000000?

Spell it out for me, baby.  :)

Re: RFA: Do solib address arithmetic with appropriate truncation

[Andrew Cagney]

> Andrew Cagney <ac131313@cygnus.com> writes:
> 
>> > There must be something around that this code can use.  On something
> 
>> >> like a mips, this would be wrong - remember the sign extension problem.
> 
>> > I've never really understood the MIPS sign extension problem.  Does
>> > it
>> > occur when TARGET_PTR_BIT is smaller than the size of one or more of
>> > the registers used to hold addresses?
> 
>> 
>> 
>> The MIPS ISA when running 32 bit code, sign extends pointers.  GDB
>> mimics this behavour.  If it encounters a 32 bit pointer it will
>> convert it to/from a cannonical form (sign extended CORE_ADDR for
>> MIPS).   Such pointers occure everywhere - debug info, registers,
>> memory, ... By always sign extending, GDB avoids any potential
>> inconsistency and latent bugs.  POINTER_TO_ADDRESS and
>> ADDRESS_TO_POINTER handle this.
>> 
>> When debugging MIPS, the first thing to check is that CORE_ADDRs are
>> sign exteded.  A value like ``0x80001234'' as the patch would
>> generate, indicate a bug.
>> 
>> Interestingly, the SPARC is showing signs of the same, or similar, problems.
> 
> 
> Let me get this straight.  From reading the .so file's section header
> table, I'm going to get 64-bit offsets, right?  And from reading the
> dynamic linker's table of loaded shared libraries, I'm going to get
> 32-bit offsets, right?


A 32 or 64 bit section header?


> So, if I have a .so section which says its offset is 0xf0000000, and
> the dynamic linker's table says that the .so has been loaded at an
> offset of 0x20000000, should I determine that the address at which the
> section was actually loaded is 0x110000000, or 0x10000000?


Assuming 64 bit section header and 32 bit offset (TARGET_PTR_BIT == 64).

0xf0000000 -> 0xfffffffff0000000
0x20000000 -> 0x0000000020000000
--------------------------------
               0x0000000010000000

Assuming a 32 bit MIPS section header and offset (TARGET_PTR_BIT == 32 
and address<->pointer is signed):

0xf0000000
0x20000000
----------
0x10000000 -> 0x0000000010000000


> Or, if the section's offset is 0x70000000, and the dynamic linker says
> the .so is loaded at an offset of 0x20000000, do I get a section address
> of 0xffffffff90000000, or 0x0000000090000000?
> 
> Spell it out for me, baby.  :)


Assuming 64 bit section header and 32 bit offset:

0x70000000 -> 0x0000000070000000
0x20000000 -> 0x0000000020000000
--------------------------------
               0x0000000090000000

Assuming a 32 bit MIPS section header and offset:

0x70000000
0x20000000
----------
0x90000000 -> 0xffffffff90000000

Andrew

Re: RFA: Do solib address arithmetic with appropriate truncation

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> Assuming a 32 bit MIPS section header and offset:
> 
> 0x70000000
> 0x20000000
> ----------
> 0x90000000 -> 0xffffffff90000000

Okay, thanks.

Now, on such a system --- 32 bit MIPS section headers and 32-bit
pointers --- where will a value like 0xffffffff90000000 ever actually
appear *on the target*?  That is, why isn't this sign extension just a
figment of GDB's imagination?

Re: RFA: Do solib address arithmetic with appropriate truncation

[Andrew Cagney]

> Andrew Cagney <ac131313@cygnus.com> writes:
> 
>> Assuming a 32 bit MIPS section header and offset:
>> 
>> 0x70000000
>> 0x20000000
>> ----------
>> 0x90000000 -> 0xffffffff90000000
> 
> 
> Okay, thanks.
> 
> Now, on such a system --- 32 bit MIPS section headers and 32-bit
> pointers --- where will a value like 0xffffffff90000000 ever actually
> appear *on the target*?  That is, why isn't this sign extension just a
> figment of GDB's imagination?


It will appear in the target's 64 bit registers.

Andrew

Re: RFA: Do solib address arithmetic with appropriate truncation

[Daniel Jacobowitz]

On Wed, Feb 06, 2002 at 02:28:59PM -0500, Jim Blandy wrote:
> 
> Andrew Cagney <ac131313@cygnus.com> writes:
> > Assuming a 32 bit MIPS section header and offset:
> > 
> > 0x70000000
> > 0x20000000
> > ----------
> > 0x90000000 -> 0xffffffff90000000
> 
> Okay, thanks.
> 
> Now, on such a system --- 32 bit MIPS section headers and 32-bit
> pointers --- where will a value like 0xffffffff90000000 ever actually
> appear *on the target*?  That is, why isn't this sign extension just a
> figment of GDB's imagination?

Just to provide an alternate wording of Andrew's answer - one of the
quirks of MIPS is that it can use a 32-bit data space, and a 32-bit ELF
format, and yet have 64-bit GPRs.  Another is that those 64-bit GPRs
may be usable in 64-bit mode from user programs, and may not be - and
might be readable by the stub in 64-bit mode or not.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer