From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21514 invoked by alias); 10 Jul 2002 23:47:21 -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 21506 invoked from network); 10 Jul 2002 23:47:20 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 10 Jul 2002 23:47:20 -0000 Received: from makita.cygnus.com (makita.sfbay.redhat.com [192.168.30.83]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id QAA02478; Wed, 10 Jul 2002 16:47:19 -0700 (PDT) Received: from localhost (keiths@localhost) by makita.cygnus.com (8.8.8+Sun/8.6.4) with ESMTP id QAA19218; Wed, 10 Jul 2002 16:47:19 -0700 (PDT) X-Authentication-Warning: makita.cygnus.com: keiths owned process doing -bs Date: Wed, 10 Jul 2002 16:47:00 -0000 From: Keith Seitz X-X-Sender: To: Greg Watson cc: Subject: Re: gdb/mi In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-07/txt/msg00111.txt.bz2 On Wed, 10 Jul 2002, Greg Watson wrote: > Seems like Apple must have already fixed this in the MacOS X version > (which is 5.0). Here is the output from 'gdb -i mi' to prove it. :-) I've already fixed this in my branch, based on Apple's work: $ ./gdb --i=mi ~"GNU gdb 2002-06-19-cvs\n" ~"Copyright 2002 Free Software Foundation, Inc.\n" ~"GDB is free software, covered by the GNU General Public License, and you are\n" ~"welcome to change it and/or distribute copies of it under certain conditions.\n" ~"Type \"show copying\" to see the conditions.\n" ~"There is absolutely no warranty for GDB. Type \"show warranty\" for details.\n" ~"This GDB was configured as \"i686-pc-linux-gnu\"." ~"\n" (gdb) We should see these changes rolling into mainline sources sometime in the coming weeks. I've still a few anomalies to hammer out. > Oh damn! I thought you'd already done the hard stuff and I could get > rid of the pty code from my front end. I guess that means that > asynchronous commands will only work with remote targets as well? Can > you point me at the approximate archive so I can review this > discussion? Yes, async on remotes only. I haven't even attempted to do this work yet. I figure sync is good enough to get my MI project moving. > Do you know if there are any plans to handle native output within the > mi syntax, or would you be interested in someone adding this > functionality, or is it likely to be too difficult? If you want to help, we could use the help. I don't think anyone is even thinking about how to do this yet, so almost anything is better than nothing. The solution to this problem is almost certainly going to differ from system to system, but we've got to start somewhere IMO. Keith