This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: CORE_ADDR representation
On Thu, 18 Feb 2010 14:41:41 +0100, Daniel Jacobowitz wrote:
> On Thu, Feb 18, 2010 at 11:34:04AM +0100, Jan Kratochvil wrote:
> > these "& mask" parts can be removed. This masking was there already before
> > start of the PIE(+OSX) patches.
>
> I don't understand. How can the masking possibly be removed? If you
> don't mask, 0x50000000 + 0x40000000 == 0x90000000 and that's not going
> to work on MIPS where we need 0xffffffff90000000.
OK, my mistake.
(You wrote somewhere MIPS32 uses only lower 2GB, expected higher 2GB is used
for some special purposes when you care about it and those lower and higher
2GB do not mix.)
> This won't show the same problem, you'll need to use mips-elf instead.
> MIPS Linux places application code below 0x80000000 exclusively; MIPS
> ELF (at least some versions) starts applications in KSEG0, at
> 0x80000000.
OK, that explains those "lower 2GB" on MIPS32.
There can be CORE_ADDR-as-address which would be always zero-extended and
CORE_ADDR-as-displacement which would be always sign-extended. Having them as
scalar types will not sanity check the code is right during compilation but it
would not need replacing all CORE_ADDR '+'/'-'es by functions calls as in:
http://sourceware.org/ml/gdb-patches/2010-02/msg00415.html
(the 200KB patch with addr_add_offset&.co.)
Thanks,
Jan