Re: [patch] Cut memory address width

[Daniel Jacobowitz <drow@false.org>]

On Thu, Sep 28, 2006 at 07:27:25PM +0200, Jan Kratochvil wrote:
> Hi,
> 
> On Wed, 27 Sep 2006 21:01:11 +0200, Mark Kettenis wrote:
> ...
> > This should almost certainly be handled in value.c:value_as_address().
> > You could add an i386-specific integer_to_address(), that would
> > truncate the address to 32 bits.  But in fact, I can't think of a
> > reason why truncating to the size of a pointer shouldn't be the
> > default behaviour.
> 
> Made the default way, I also do not see the reason to keep larger addresses.
> There is some note about `ADDR_BITS_REMOVE' but I believe it is only about the
> lowest (0-2 or so) bits and the high bits should not hurt anyone.

Please see the other message in this thread where I explained about
MIPS; there, all 0x80000000 - 0xFFFFFFFF addresses will be sign
extended.  Suddenly printing out the extra eight F's would be really
ugly IMHO.  I tried to come up with a good solution to this today, but
I couldn't find one; the flag we need is associated with the BFD and
not easily accessible here.  Maybe there should be a gdbarch flag
for the property; only MIPS and sh64 set it, so duplicating the
knowledge here isn't a big deal.

As for the other half of the bug, Mark was talking about
integer_to_address, which is separate from value_to_address where your
patch tried to fix this.  I think that either inside the
implementations of that function, or at the one call site, is where we
should fix it.  That will avoid creating such addresses in the first
place. There are two options: ignore high bits, or complain if the high
bits would affect the address (e.g. if the integer was not properly
sign or value extended).  Mark liked truncate, I don't really care
which.

Oh, and please don't #if 0 things.  Either they're right, or they're
wrong.  If we need them again, there's CVS history.  Thanks in advance.

-- 
Daniel Jacobowitz
CodeSourcery