This is the mail archive of the gdb@sourceware.cygnus.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]

Re: deferred stores as a solution to store register api?


"J.T. Conklin" wrote:

> Andrew> I agree with your comment that the target api needs to be
> Andrew> extended so that high-gdb can tell low-gdb (target) that it is
> Andrew> performing a batched update and, as you suggest, something
> Andrew> like _defered_store() will make that more efficient.  I just
> Andrew> also think we may need to add some extra code so that the
> Andrew> existing behavour (each command is atomic ???) is also
> Andrew> retained.
> 
> The window where GDB holds state that the target does not would be
> tightened if we add a target_do_deferred_store() after commands have
> completed execution.  Would this be enough?

That would do it but I don't know that such code should be telling the
target directly to push out those registers. Refering to that bad ascii
art:

          High GDB
             |
            \|/
       pseudo reg-nr
             |
        map pseudo <->
        random cache
        bytes       
             |
            \|/
        ------------
        | register |
        |  cache   |
        ------------
            /|\
             |
        map random cache
        bytes to target
        dependant i-face
            /|\
             |
       target dependant
        such as [gG] packet
        or ptrace buffer

at the end of a command, high gdb could elect to tell the cache to purge
its self and that would in turn lead to the cache telling the target to
store_register() + do_defered_stores().  Having high gdb call
target_do_defered_stores() directly would need to be an interim measure.

	Andrew

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