This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Multiplexed registers and invalidating the register cache
Andrew Cagney wrote:
- the frame cache is built on-demand, hence the absence of any explict
rebuild call (one characteristic of a frame ID is that it survives frame
cache flushes)
In other words, I shouldn't expect to see a whole lot of communication
with the remote target simply because I flush the frame cache.
- there shouldn't be separate register and frame flush calls, combining
the two into a single observer call is a thing-to-do-today
Ok, let's see if I understand this correctly. Sorry if I'm asking what
is (or should be) obvious (I only see observer.exp using this code as of
now, so it's not clear to me how this is supposed to be used within GDB).
A new event needs to be defined (user_changed_registers(?), taking the
register number as an argument). This will give us attach/detach/notify
functions related to that event. So, someone needs to attach a
callback: is this something that should be done in target-specific files?
If so, should targets provide their own callback implementation (which
flushes the register and frame cache when deemed appropriate), or should
there be a predefined function that the target-specific file simply
references when attaching the callback?
In addition, someone needs to notify that the event has happened, but I
assume these notifications should be inserted at the same places that
register_changed_hook is called for GUI purposes.
Anything I missed or misunderstood?
--
Orjan Friberg
Axis Communications