From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6199 invoked by alias); 14 Mar 2005 19:11:50 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 6109 invoked from network); 14 Mar 2005 19:11:44 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 14 Mar 2005 19:11:44 -0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j2EJBcji003770 for ; Mon, 14 Mar 2005 11:11:40 -0800 (PST) Received: from relay1.apple.com (relay1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Mon, 14 Mar 2005 10:48:25 -0800 Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id j2EImLOK019332 for ; Mon, 14 Mar 2005 10:48:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v718) In-Reply-To: <1110656346.18541.ezmlm@sources.redhat.com> References: <1110656346.18541.ezmlm@sources.redhat.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI output command error Date: Mon, 14 Mar 2005 19:11:00 -0000 To: gdb@sources.redhat.com X-SW-Source: 2005-03/txt/msg00153.txt.bz2 Eli is right, gdb was changed to HAVE an event loop, which made handling async targets possible. But then the target itself needed to be made asynchronous as well. There is a remote async target already, though I don't know how well it works. For a ptrace based target (most native targets) you need to have a separate thread to run wait4 which then communicates back to the event source through some kind of signal. For procfs, I bet it would be even easier, since then you could just make an event source for the various proc files you need to watch and add them to the general "select" call that also waits for command input. We made this work (for a ptrace-like setup) on Mac OS X. There were a bunch of little bugs we had to deal with (like breakpoint commands that can restart the target are a little tricky when you have an async target). There was a bunch of fiddling necessary to make it stable, but it wasn't all that hard. It certainly is useful from a GUI to be able to interrupt, and almost more important to be able to ask gdb "are you running the target or not?" which can help sync up the GUI if things get confused as they sometimes do... Jim On Mar 12, 2005, at 11:39 AM, gdb-digest-help@sources.redhat.com wrote: >> From: Nick Roberts >> Date: Sat, 12 Mar 2005 10:49:41 +1300 >> Cc: Dave Korn , >> Karganov Konstantin , GDB >> >> >>> Lack of implementation. No one's done the work. >> >> Thats understandable. However, given that MI was introduced in GDB >> 5.0, I >> think there should be something in the manual explaining this as >> it seems to >> create a lot of confusion. It needs to be written by someone who >> understands >> the issue i.e not myself. > > I'm all for documenting this in some useful way, but I fail to see how > could this be done. Describing the async operation itself is already > a big challenge, as the details are extremely confusing, unless you've > read the code several times and have a good understanding of the > underlying system calls (like `poll' and `select'). Differences > between interpreters add another dimension of complexity to this. > >> I believe that operation is asynchronous with certain targets, >> although I have never managed to create these conditions, even with >> gdbserver over TCP. > > Actually, I think that the asynchronous operation is independent of > the target. The infrastructure for this is in event-loop.c, which is > not specific to any target. > > The problem with implementing async operation with the CLI interface > is, AFAIU, not its dependence on some target-specific feature, but > rather the need to redesig the CLI front end to do something useful > while waiting for a prolonged operation to run to completion. For GUI > front ends, such as those who use MI, it's clear what to do during > that time, and the separate-process implementation makes it even > easier to design. By contrast, the CLI interface is part of the GDB > process. > > I don't consider myself a specialist in these matters, so please take > the above with a grain of salt (i.e., it might all be wrong ;-). >