From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29548 invoked by alias); 19 Jun 2005 22:12:58 -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 29527 invoked by uid 22791); 19 Jun 2005 22:12:54 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 19 Jun 2005 22:12:54 +0000 Received: from drow by nevyn.them.org with local (Exim 4.51) id 1Dk827-0005KE-2O; Sun, 19 Jun 2005 18:12:51 -0400 Date: Sun, 19 Jun 2005 22:12:00 -0000 From: Daniel Jacobowitz To: Jason Molenda Cc: Nick Roberts , gdb-patches@sources.redhat.com Subject: Re: [PATCH] -stack-info-frames Message-ID: <20050619221251.GA20266@nevyn.them.org> Mail-Followup-To: Jason Molenda , Nick Roberts , gdb-patches@sources.redhat.com References: <17075.21529.964955.923197@farnswood.snap.net.nz> <20050617230130.GB21178@nevyn.them.org> <20050617231425.GA22254@nevyn.them.org> <17075.30993.384316.356236@farnswood.snap.net.nz> <20050618015756.GA30430@nevyn.them.org> <17075.57612.684597.392526@farnswood.snap.net.nz> <20050618155742.GB3663@nevyn.them.org> <17076.42233.730605.834264@farnswood.snap.net.nz> <20050619145505.A24148@molenda.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050619145505.A24148@molenda.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-06/txt/msg00299.txt.bz2 On Sun, Jun 19, 2005 at 02:55:05PM -0700, Jason Molenda wrote: > 86^done,MI_HOOK_RESULT=[HOOK_TYPE="frame_changed",frame="1"] Yes, I am absolutely positive that we're going to need something like this, though I'm not sure the model will be quite the same. On and off I have been working on a better interface for binding scripting languages to GDB. I have guile mostly working - the only hassle is that I don't know squat about actually programming in guile, so I can't write any of the script-side support code that it needs. It should be a cinch to add other languages, e.g. Python or to merge Kip's Perl bindings. But the way my interface works, it talks to GDB over an MI interpreter. We need to find some way to keep an MI frontend informed of what happens while "its" interpreter is not connected. What I'm thinking is that we should be able to have a primary interpreter and multiple less-primary ones; only one accepts input at a time; most commands only respond to the console they got input from; and certain notifications, sort of like annotations in principle, go to any open channels. -- Daniel Jacobowitz CodeSourcery, LLC