RFC: Unpredictable register set operations

RFC: Unpredictable register set operations

[Daniel Jacobowitz]

I'm sure this has come up before, but I couldn't find a discussion anywhere
so I'll just have to ask again...

Consider PowerPC and the $ps register (MSR).  When debugging a kernel or
embedded application, GDB has pretty complete control (?) over this
register.  In GNU/Linux userspace, however, only two bits of it can be set. 
The rest are read-only.

So what happens if you "set $ps = 0"?  Well, the right thing happens, but
until the next time the target stops "print $ps" will print 0.  Which is not
actually the value of the $ps register.

Here's the options that I see:
  - Ignore and document this.
  - Refetch registers after storing them.
  - Invalidate registers for lazy re-fetch after storing them.
  - Add a target hook for might-be-volatile registers, and invalidate
    only those registers after storing them - or don't cache them at
    all.

Thoughts?  Is this a problem worth fixing?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Unpredictable register set operations

[Kevin Buettner]

On Jul 15,  6:09pm, Daniel Jacobowitz wrote:

> Consider PowerPC and the $ps register (MSR).  When debugging a kernel or
> embedded application, GDB has pretty complete control (?) over this
> register.  In GNU/Linux userspace, however, only two bits of it can be set. 
> The rest are read-only.
> 
> So what happens if you "set $ps = 0"?  Well, the right thing happens, but
> until the next time the target stops "print $ps" will print 0.  Which is not
> actually the value of the $ps register.
> 
> Here's the options that I see:
>   - Ignore and document this.
>   - Refetch registers after storing them.
>   - Invalidate registers for lazy re-fetch after storing them.
>   - Add a target hook for might-be-volatile registers, and invalidate
>     only those registers after storing them - or don't cache them at
>     all.

One of the refetch options (lazy or not) sounds good to me.  The
target hook idea sounds like overkill, and I think we can do better
than "ignore and document".

Kevin

RFC: Unpredictable register set operations

[Doug Evans]

Daniel Jacobowitz writes:
 > So what happens if you "set $ps = 0"?  Well, the right thing happens, but
 > until the next time the target stops "print $ps" will print 0.  Which is not
 > actually the value of the $ps register.
 > 
 > Thoughts?  Is this a problem worth fixing?

Definately worth fixing.

In complex systems there may be various scripts that make use of
these register's values.
Having these scripts randomly break because gdb is lying to the script
about what the value of the register is is, well, not nice.

Re: RFC: Unpredictable register set operations

[Andrew Cagney]

> I'm sure this has come up before, but I couldn't find a discussion anywhere
> so I'll just have to ask again...

It come up before:
http://sources.redhat.com/ml/gdb/2003-06/msg00108.html

> Consider PowerPC and the $ps register (MSR).  When debugging a kernel or
> embedded application, GDB has pretty complete control (?) over this
> register.  In GNU/Linux userspace, however, only two bits of it can be set. 
> The rest are read-only.
> 
> So what happens if you "set $ps = 0"?  Well, the right thing happens, but
> until the next time the target stops "print $ps" will print 0.  Which is not
> actually the value of the $ps register.
> 
> Here's the options that I see:
>   - Ignore and document this.
>   - Refetch registers after storing them.
>   - Invalidate registers for lazy re-fetch after storing them.
>   - Add a target hook for might-be-volatile registers, and invalidate
>     only those registers after storing them - or don't cache them at
>     all.
> 
> Thoughts?  Is this a problem worth fixing?

This is a straight bug.  The register cache should be marked as invalid 
after the store.   What puzzles me is why store.exp doesn't tickle this, 
or is this a hangover from lval_register vs lval_reg_frame_relative?

Andrew

Re: RFC: Unpredictable register set operations

[Daniel Jacobowitz]

On Tue, Jul 15, 2003 at 10:46:44PM -0400, Andrew Cagney wrote:
> >I'm sure this has come up before, but I couldn't find a discussion anywhere
> >so I'll just have to ask again...
> 
> It come up before:
> http://sources.redhat.com/ml/gdb/2003-06/msg00108.html
> 
> >Consider PowerPC and the $ps register (MSR).  When debugging a kernel or
> >embedded application, GDB has pretty complete control (?) over this
> >register.  In GNU/Linux userspace, however, only two bits of it can be 
> >set. The rest are read-only.
> >
> >So what happens if you "set $ps = 0"?  Well, the right thing happens, but
> >until the next time the target stops "print $ps" will print 0.  Which is 
> >not
> >actually the value of the $ps register.
> >
> >Here's the options that I see:
> >  - Ignore and document this.
> >  - Refetch registers after storing them.
> >  - Invalidate registers for lazy re-fetch after storing them.
> >  - Add a target hook for might-be-volatile registers, and invalidate
> >    only those registers after storing them - or don't cache them at
> >    all.
> >
> >Thoughts?  Is this a problem worth fixing?
> 
> This is a straight bug.  The register cache should be marked as invalid 
> after the store.   What puzzles me is why store.exp doesn't tickle this, 
> or is this a hangover from lval_register vs lval_reg_frame_relative?

Where's the invalidation supposed to happen presently?  Perhaps I need
to retest.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Unpredictable register set operations

[Daniel Jacobowitz]

On Tue, Jul 15, 2003 at 11:21:18PM -0400, Daniel Jacobowitz wrote:
> On Tue, Jul 15, 2003 at 10:46:44PM -0400, Andrew Cagney wrote:
> > >I'm sure this has come up before, but I couldn't find a discussion anywhere
> > >so I'll just have to ask again...
> > 
> > It come up before:
> > http://sources.redhat.com/ml/gdb/2003-06/msg00108.html
> > 
> > >Consider PowerPC and the $ps register (MSR).  When debugging a kernel or
> > >embedded application, GDB has pretty complete control (?) over this
> > >register.  In GNU/Linux userspace, however, only two bits of it can be 
> > >set. The rest are read-only.
> > >
> > >So what happens if you "set $ps = 0"?  Well, the right thing happens, but
> > >until the next time the target stops "print $ps" will print 0.  Which is 
> > >not
> > >actually the value of the $ps register.
> > >
> > >Here's the options that I see:
> > >  - Ignore and document this.
> > >  - Refetch registers after storing them.
> > >  - Invalidate registers for lazy re-fetch after storing them.
> > >  - Add a target hook for might-be-volatile registers, and invalidate
> > >    only those registers after storing them - or don't cache them at
> > >    all.
> > >
> > >Thoughts?  Is this a problem worth fixing?
> > 
> > This is a straight bug.  The register cache should be marked as invalid 
> > after the store.   What puzzles me is why store.exp doesn't tickle this, 
> > or is this a hangover from lval_register vs lval_reg_frame_relative?
> 
> Where's the invalidation supposed to happen presently?  Perhaps I need
> to retest.

I don't know if we're talking about the same thing, but this definitely
doesn't happen now.  I believe we invalidate the frame cache, not
the current regcache... try it, for example on a remote ARM target:

set debug remote 1
info registers
[see the g packet]
set $r0 = 2
[see the G packet]
info registers
[from the cache, no packets on the wire]

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Unpredictable register set operations

[Andrew Cagney]

> This is a straight bug.  The register cache should be marked as invalid 
>> > after the store.   What puzzles me is why store.exp doesn't tickle this, 
>> > or is this a hangover from lval_register vs lval_reg_frame_relative?
> 
>> 
>> Where's the invalidation supposed to happen presently?  Perhaps I need
>> to retest.
> 
> 
> I don't know if we're talking about the same thing, but this definitely
> doesn't happen now.  I believe we invalidate the frame cache, not
> the current regcache... try it, for example on a remote ARM target:
> 
> set debug remote 1
> info registers
> [see the g packet]
> set $r0 = 2
> [see the G packet]
> info registers
> [from the cache, no packets on the wire]

Sounds like it never did.  It needs to though (the missing function 
target_changed).  After a write, the target state should be flushed.

Andrew