Re: [rfc] Adjust address size on MIPS

[Daniel Jacobowitz <drow@false.org>]

On Fri, Aug 03, 2007 at 08:37:28PM +0200, Mark Kettenis wrote:
> > Date: Fri, 3 Aug 2007 13:58:22 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > I recently tried to use a 64-bit stub to debug an O32 MIPS program.
> > It fell down because GDB would send a "m83000000" packet, instead of
> > the proper "mffffffff83000000" packet (sign extended 64-bit
> > addresses).  I think that if a stub sends us some 64-bit registers in
> > the "g" packet, the polite thing to do would be to send it 64-bit
> > addresses by default.
> > 
> > Does this sound wrong to anyone? 
> 
> This feels like a bad hack to me.  If it is sending 64-bit addresses
> should PROPERTY_GP64 be set in the first place?

Isn't that exactly when it should be set?

Some context - I'm not sure how much of this you're already familiar
with, probably quite a bit.

The remote stub is controlling some program (about which it may know
very little) and has some register/address size (which may be
independent of the program).  This comes about because you can run an
o32 program unmodified in a 64-bit environment.

What's happening to me right now is that the remote stub is 64-bit,
but the program is 32-bit.  GDB sees that registers are 64-bit and
sets the gdbarch appropriately.  But since the program is o32, GDB
knows that pointers are 32-bit, and then uses that as the address
size.  So we set a breakpoint at "0x83000000" based on the address in
the symbol file.

If we were a well-behaved MIPS o32 program using a store instruction,
this would be sign extended behind the scenes and everything would be
happy.  But in the world of the 64-bit stub, you might have 4G RAM at
0 and a different 4G RAM at 0xffffffff00000000.  The stub doesn't know
which one of those we mean, so it takes us at our word and tries
0x83000000.  Which, if you have less than 3GB of RAM, is probably not
mapped as a 64-bit address.

-- 
Daniel Jacobowitz
CodeSourcery