Re: RFA: Do solib address arithmetic with appropriate truncation

[Jim Blandy <jimb at zwingli dot cygnus dot com>]

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