This is the mail archive of the gdb-patches@sourceware.org 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: MI output during program execution



On Aug 9, 2005, at 11:23 AM, Bob Rossi wrote:


On Tue, Aug 09, 2005 at 10:59:25AM -0700, Jim Ingham wrote:

The front end needs to know if a CLI command executed via "-
interpreter-exec console" changed the current thread or frame - so it
can update the UI accordingly.  Or if it started the target running.
Or if it added a breakpoint.

All these things could be queried from existing commands in the MI,
but that's pretty inconvenient and inefficient.  It's much easier to
code up the UI if gdb tells it asynchronously about these things.


OK, well then I completly agree that observers would be a very nice way
to solve this problem. When an internal MI state changes, it should
alert the FE if the FE requested such knowledge. This is of course, an
asyncronous approach as far as the FE is concerned. If the FE needs this
information now, it can simply poll GDB for this information.


Also, I'm not convinced it would be inefficient to query GDB for the
required information, especially if a new MI command was added to GDB
that returned the current state of GDB. (frame,thread,file).

"Run over all state and see what changed" is a pain compared to "tell me when something changes". If the former were hard to code up for some reason, I guess you could go for the latter, but it didn't take all that much thought to get this working...



How does -interpreter-exec console work in the case when the user executes a command, that makes up several other commands?

define mess_with_mi_people
   b main
   r
   n
   n
end

I don't think this case would currently work as expected. Would it?

Remember that only one "run the target" command is allowed in a CLI define. All the others are ignored.


But anyway, in our setup, the UI would get notification that a breakpoint was set, and then that the target continued.

A harder one to handle is:

define really_mess_with_people
     break function_that_gets_hit_alot
     commands $bpnum
         print someInterestingVariable
         continue
     end
     r
end

because then you are going to get the breakpoint notification, then the run notification, then the breakpoint hit, at which point the target is going to start again, etc... I don't see how you really solve this one with the UI polling for state. But with the hooks and just a little bit of judicious trickery (we added a "breakpoint commands running" and "breakpoint commands done running" events so the UI would know to hold off doing it's "breakpoint hit handling" till the commands were done) we have this one working as well.

Jim


Thanks, Bob Rossi



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