This is the mail archive of the gdb@sourceware.org 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]
Other format: [Raw text]

Re: Problem with breakpoint addresses


On Fri, Oct 13, 2006 at 09:19:15AM +0100, Andrew STUBBS wrote:
> Michael Snyder wrote:
> >What's the size of $r1, and what's the size of an address?
> >By converting $r1 to an address, you're applying an implied cast.
> >If that doesn't give the expected result (eg. because $r1 is signed),
> >then you need to use an explicit cast.
> 
> Registers are 32 bit, addresses are 32 bit. It's just something in GDB 
> that uses 64 bit. It might be because sh-elf also supports sh64.
> 
> In any case, it is successfully setting the breakpoint and then failing 
> to recognise it when it is hit. That isn't the behaviour I would like. 
> If it totally failed to set it then giving the cast might be fair 
> enough, if the user thought addresses were 64 bit.

This sounds an awful lot like the discussion just recently on
gdb-patches about paddress and target_read_memory (started by
Jan).

First of all, should addresses be considered sign extended on SH?
Since BFD says that elf32-sh64 uses address sign extension, I suspect
it should, but really it doesn't much matter if you're connected to a
32-bit target.  So we can assume not for now.

Secondly, this is just our use of CORE_ADDR as a native arithmetic type
coming home to byte us.  We knew it would someday.  I think you should
figure out where the sign extended CORE_ADDR was created, and why.
I hope it was in value_as_address.  This isn't a right final fix, but
could you see if setting gdbarch_integer_to_address to a function that
always uses extract_unsigned_integer helps?

-- 
Daniel Jacobowitz
CodeSourcery


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