Problem with breakpoint addresses

Problem with breakpoint addresses

[Andrew STUBBS]

Hi,

I have a problem setting breakpoints from addresses stored in registers.

Here's an example:

(gdb) set $r1 = 0x80000000
(gdb) b *$r1
Breakpoint 2 at 0x80000000

The breakpoint looks like it is set correctly, but actually, if it is to 
work, I have to set it like this:

(gdb) b *($r1 & ~0U)
Breakpoint 3 at 0x80000000

This shows the difference:

(gdb) info breakpoints
Num Type           Disp Enb Address    What
2   breakpoint     keep y   0xffffffff80000000
3   breakpoint     keep y   0x80000000

The address has been sign extended. Note that there is no problem with 
registers of unsigned type. This is with an sh-elf target hosted on 
i686-pc-linux-gnu and using 'target sim'.

The effect of this is that the breakpoint is placed correctly, but, once 
hit, the program cannot continue or step any further.

The problem appears to be that the 32 bit address is used to set the 
breakpoint (i.e. the 64 bit address is truncated somewhere in the 
system), but when it is hit GDB does the address comparison and the 
addresses are not the same so the breakpoint is not recognised.

My question is: what is the _correct_ fix for this issue?

Should it never do sign extension? Should it always do sign extension? 
Is there some way to identify when it is intended and when not? Or 
perhaps the true problem is elsewhere entirely?

Andrew Stubbs

Re: Problem with breakpoint addresses

[Michael Snyder]

On Thu, 2006-10-12 at 18:54 +0100, Andrew STUBBS wrote:
> Hi,
> 
> I have a problem setting breakpoints from addresses stored in registers.
> 
> Here's an example:
> 
> (gdb) set $r1 = 0x80000000
> (gdb) b *$r1
> Breakpoint 2 at 0x80000000
> 
> The breakpoint looks like it is set correctly, but actually, if it is to 
> work, I have to set it like this:
> 
> (gdb) b *($r1 & ~0U)
> Breakpoint 3 at 0x80000000
> 
> This shows the difference:
> 
> (gdb) info breakpoints
> Num Type           Disp Enb Address    What
> 2   breakpoint     keep y   0xffffffff80000000
> 3   breakpoint     keep y   0x80000000
> 
> The address has been sign extended. Note that there is no problem with 
> registers of unsigned type. This is with an sh-elf target hosted on 
> i686-pc-linux-gnu and using 'target sim'.

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.

Re: Problem with breakpoint addresses

[Andrew STUBBS]

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.

Andrew

Re: Problem with breakpoint addresses

[Daniel Jacobowitz]

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

Re: Problem with breakpoint addresses

[Michael Snyder]

On Fri, 2006-10-13 at 09:19 +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.

Hmmm.  Well, gdb's internal representation of a target address is
a typedef COREADDR, and usually it equates to a long long (64 bits).

Seems like, if we know that for a given architecture, an actual
target address is only 32 bits, we should always make sure to 
save only 32 bits into a COREADDR.

Maybe its time we made COREADDR into a first class object, with 
accessor methods.  I know, I know, we can only pretend to do it in
C, but we already do treat a number of things like objects.

Re: Problem with breakpoint addresses

[Mark Kettenis]

> From: Michael Snyder <Michael.Snyder@palmsource.com>
> Date: Fri, 13 Oct 2006 11:38:49 -0700
> 
> On Fri, 2006-10-13 at 09:19 +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.
> 
> Hmmm.  Well, gdb's internal representation of a target address is
> a typedef COREADDR, and usually it equates to a long long (64 bits).

Actually, in many cases it isn't.  If you're on a 32-bit host and
configure for a purely 32-bit target, CORE_ADDR will be a 32-bit type.

> Seems like, if we know that for a given architecture, an actual
> target address is only 32 bits, we should always make sure to 
> save only 32 bits into a COREADDR.

Indeed.  This is basically what I suggested to Jan to solve his
problem.

Mark

Re: Problem with breakpoint addresses

[Andrew STUBBS]

Sorry it's taken me a little while to get back to this.

Daniel Jacobowitz wrote:
> 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?

This fix does indeed solve the problem. Thanks.

Why do you think this isn't the right final fix? I can't think of an 
example of why this wouldn't always work until SH5, but the fix need not 
affect that.

Andrew

Re: Problem with breakpoint addresses

[Daniel Jacobowitz]

On Mon, Oct 30, 2006 at 04:17:02PM +0000, Andrew STUBBS wrote:
> Sorry it's taken me a little while to get back to this.
> 
> Daniel Jacobowitz wrote:
> >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?
> 
> This fix does indeed solve the problem. Thanks.
> 
> Why do you think this isn't the right final fix? I can't think of an 
> example of why this wouldn't always work until SH5, but the fix need not 
> affect that.

I can't remember how my logic went.  Should have written more of it
down.

Some day, I think we're going to need to do as Mark and Michael
suggested; stop using CORE_ADDR so indiscriminately as a convenient
integer type.  In the mean time, perhaps everywhere that doesn't
define integer_to_address should get a better default, or the fallback
case in value_as_address should be changed, so that this is fixed
equally on other platforms.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Problem with breakpoint addresses

[Andrew STUBBS]

Daniel Jacobowitz wrote:
> Some day, I think we're going to need to do as Mark and Michael
> suggested; stop using CORE_ADDR so indiscriminately as a convenient
> integer type.  In the mean time, perhaps everywhere that doesn't
> define integer_to_address should get a better default, or the fallback
> case in value_as_address should be changed, so that this is fixed
> equally on other platforms.

Hmmm, well some of those platforms, such as sh64, like the current 
default behaviour as it is.

Meanwhile, those that do not like it have the option of overriding it 
using integer_to_address. I assume those targets that don't have a 64 
bit variant only care about this on 64 bit hosts, so only mips bothers 
to implement integer_to_address so far (AFAICS).

Perhaps the correct fix is to define a default address width for each 
target variant, but that seems like more work than is really necessary.

Should I post my patch or work up something else?

Andrew

Re: Problem with breakpoint addresses

[Daniel Jacobowitz]

On Mon, Oct 30, 2006 at 04:54:51PM +0000, Andrew STUBBS wrote:
> Daniel Jacobowitz wrote:
> >Some day, I think we're going to need to do as Mark and Michael
> >suggested; stop using CORE_ADDR so indiscriminately as a convenient
> >integer type.  In the mean time, perhaps everywhere that doesn't
> >define integer_to_address should get a better default, or the fallback
> >case in value_as_address should be changed, so that this is fixed
> >equally on other platforms.
> 
> Hmmm, well some of those platforms, such as sh64, like the current 
> default behaviour as it is.

They should explicitly have a sign extending method set then.  See
MIPS.  Now it depends if your register has type "int" or "uint",
which really shouldn't matter.

> Perhaps the correct fix is to define a default address width for each 
> target variant, but that seems like more work than is really necessary.
> 
> Should I post my patch or work up something else?

Dunno.  Fixing SH is better than fixing nothing.

-- 
Daniel Jacobowitz
CodeSourcery