This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gdb 5.0: solib.c (LM_ADDR) should be signed, not unsigned


On Wed, 26 Jul 2000, Andrew Cagney wrote:

> I don't think this is right.  I think it would sign extend that address
> for all targets - wrong in 99% of cases.  

 It *is* right indeed.  See the SYSV ABI.  Despite its confusing name the
load address is a *difference* between the load-time address and the
link-time base address, i.e. it's a value a shared object gets relocated. 
An unsigned difference just makes no sense -- there is no requirement only
to forward relocating shared objects.  You must not confuse the load
address with the base address.

> Can you provide more information on the problem you're seeing (+
> host/target etc).

 It can potentially be observed for every shared object which gets linked
with its base address greater than zero.  It is usually set via a linker
script.  It's commonly observed on MIPS/Linux systems, where the base
address in default linker scripts is set to 0x5ffe0000 but the address
mmap() starts putting objects from is set to 0x2aaaaaaa, thus unless
a system is short on memory shared objects get relocated backward.  If the
exact values shown were used the load address would be -0x35535556 or
0xcaacaaaa, which must be appropriately sign-extended.

 If a zero-extended value is used instead, gdb cannot compute symbol
addresses within shared objects correctly -- basically they do not work at
all. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]