From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25193 invoked by alias); 2 Oct 2002 17:49:35 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25093 invoked from network); 2 Oct 2002 17:49:32 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 2 Oct 2002 17:49:32 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g92HnSs06293 for ; Wed, 2 Oct 2002 10:49:28 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 2 Oct 2002 10:49:20 -0700 Received: from inghji.apple.com (inghji.apple.com [17.201.22.240]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g92HnRb27347; Wed, 2 Oct 2002 10:49:27 -0700 (PDT) Date: Wed, 02 Oct 2002 10:49:00 -0000 Subject: Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: gdb-patches@sources.redhat.com To: Keith Seitz From: Jim Ingham In-Reply-To: Message-Id: <274865DD-D62F-11D6-BB61-00039379E320@apple.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00061.txt.bz2 On Wednesday, October 2, 2002, at 08:01 AM, Keith Seitz wrote: > 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). In large part, it is just that if I can track cause & effect unambiguously, everything is much cleaner. From PB, I issue a command, I want to tick off when that command succeeded, and gather all the data from the result I need. If I get a note back from gdb saying, "The third command down in the command stream that you issued, here is the result to it." then I can do this without any effort. However, in your proposed implementation, I have to peer at the command stream and wait both for an anonymous breakpoint created message, and a for the done message (to know things are formally done, and because it would be very dangerous to just toss aside bits of the output stream, since it reduces your chances of catching & handling errors intelligently.) Then I have to use some smarts to tie the breakpoint created message to the particular message I sent to gdb. This is harder to do, and fragile. In my mind, one of the major advantages of the MI was that it made this tie between the command you sent and the result that came from it explicit and unambiguous. This was in response to a lot of the pain that we suffered in insight where any random spew from the command line would get itself inserted into the "results" of the command you thought you were executing. You are breaking this tie by moving the results of a command from the command result to an untagged asynchronous event. For breakpoints, this is probably just an inconvenience. But if we follow this as a principle, then in more complex cases, where it is not so easy to tell whether an asynchronous notification arose from a command initiated by the MI, or from some other action we will likely start getting confused again. For instance, we might have something happening in the target, or some console command, or something more gnarly like the results of a breakpoint command which also continued the target while you thought it was just running... In short, you are breaking one of the core parts of the MI model, for no very apparent reason. In this case, it might be benign, but it is a very useful part of the design, and the reasons for doing it are very weak. > > 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. Not quite. Rather we want to issue commands in batches, and then link the results of the commands back up to the individual commands. This is often a very convenient way to proceed. And I would rather have the linkage be explicit, because matching the commands to results by inspecting the sequencing of the result is fragile and error-prone. > > 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? Remember that PB persists over individual runs of the gdb debugger (and can, in fact, be running multiple copies of gdb, one for each project). Also,we keep a Breakpoints window that persists between runs of PB, so the user can have all his/her favorite breakpoints persist over PB sessions. So we have to have an object on the PB side that represents each breakpoint before we have even thought about starting up gdb. Each one of these PB breakpoints is going to result in a gdb breakpoint at some time. When I go to take the PB breakpoint object & insert it into the current instance of the gdb debugger, I would like to get the right breakpoint number back into the associated PB breakpoint object. I can very easily do this if I can tie the results of the command that sends the breakpoint to gdb to the initial command. Otherwise I have to do unnecessary work whose only benefit is it gives me a chance to make a mistake somewhere. Jim -- Jim Ingham jingham@apple.com Developer Tools Apple Computer