Re: Events when inferior is modified

[Nick Bull <nicholaspbull@gmail.com>]

Tom,

Thanks for your comments: I'll modify and resubmit.

On 30 July 2013 22:04, Tom Tromey <tromey@redhat.com> wrote:
>
> I'm curious to know why you wanted pre- and post-observers for inferior
> calls, but not anything else.
[...]
>
> It seem to me that this may just be an approximation of "dirty" in the
> remote case.  E.g., gdbserver may write a breakpoint and otherwise
> modify things without notifying gdb.
>
> On the other hand, maybe you want to rule out breakpoints from being
> considered "dirty".  But then the change has to be more complicated in
> another way.

The sense of "dirty" that I'm using is "the user has interfered with
program state", and not for example "gdb has some cached data which is
now stale".

For context, I'm using this patch in a system with a lot of Python
scripting around gdb to support the user in various ways. I'm also
only concerned with the remote gdbserver case, should that be
relevant.

The motivation behind this work is that the user, sitting at the gdb
command line trying to debug their program, has the ability to modify
the program's state under its feet and hence change its future
behaviour. Which is potentially useful in exploring fixes without
recompiling, but carries the risk that you leave a change in and carry
on, forgetting that you're not debugging the real system any more. I
don't want to totally prevent that kind of modification, but I do want
to know that it has happened. Various UI options are possible at that
point, such as emitting warnings, changing the prompt etc, but those
choices can all be made in the scripting layer.

Breakpoints aren't a modification for these purposes, as they don't
cause the debugged program to generate different results. Well, I hope
not.

Inferior function calls are useful in conditional breakpoints and for
interrogating data structures, but sometimes they perturb the program
state and sometimes they don't. Ignoring the synthesized stack frame
on which they were called, of course. By receiving observer events
before and after the call, we can work behind the user's back to check
for differences. Again, what we do about that---issuing a warning, or
maybe even reverting the changes---can be decided at a higher level.

Picking up changes to registers and memory is a bonus feature for me,
rather than essential, as it's an explicit choice to change state
whereas a fn call may just read state. And per Pedro's comment, other
ways to modify program state are possible, but haven't tripped me up
yet; so in that respect the itch is sufficiently scratched for now.

Nick