This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: gdb 5.0: solib.c (LM_ADDR) should be signed, not unsigned
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: gdb 5.0: solib.c (LM_ADDR) should be signed, not unsigned
- From: "Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>
- Date: Wed, 26 Jul 2000 11:03:20 +0200 (MET DST)
- cc: gdb-patches at sourceware dot cygnus dot com
- Organization: Technical University of Gdansk
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 +