This is the mail archive of the gdb@sources.redhat.com 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: RFC: Unpredictable register set operations


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



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