Re: RFA: Do solib address arithmetic with appropriate truncation

[Jim Blandy <jimb@zwingli.cygnus.com>]

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