This is the mail archive of the
mailing list for the GDB project.
Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0
- From: Keith Seitz <keiths at redhat dot com>
- To: Jim Ingham <jingham at apple dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 2 Oct 2002 08:01:02 -0700 (PDT)
- Subject: Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0
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?