Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0

[Keith Seitz <keiths@redhat.com>]

On Tue, 1 Oct 2002, Jim Ingham wrote:

> I don't want a tight coupling in TIME, or in the output sequence.  I 
> want meta-info which tells me with 100% certainty that this result is 
> the result of command foo, that I sent some time in the past, precisely 
> so I DON'T have to rely on anything about the sequencing of input or 
> output to make this connection.

Ok, but this is exactly what I don't understand: what does it matter where 
the breakpoint comes from? All that matters is that you have issued a 
command, and you don't do anything out of the normaluntil an event from 
GDB telling you that it has set a breakpoint. You just sit in your event 
loop waiting for any event (GUI, paint, GDB, blah blah blah).

Insight has used a method exactly like this now for over a year. When a 
breakpoint is set, Insight tells gdb to set it. It then returns to the 
command loop. It doesn't do anything else. It's not waiting for anything. 
When the breakpoint event comes from gdb, it creates its breakpoint object 
and passes it around. The source window gets it and places a breakpoint at 
the appropriate place. I can only assume that you've got private data that 
you need to associate with commands and that this data is lost when 
returning to the event loop.

Please help me understand why it is so important to know exactly what 
command prompted a breakpoint event. I still just don't get it. Can you 
give me a specific example of when it would be useful to know that command 
A elicited breakpoint event A' instead of command B?

Sorry.
Keith