This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
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