From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29454 invoked by alias); 31 Jul 2007 19:18:22 -0000 Received: (qmail 29440 invoked by uid 22791); 31 Jul 2007 19:18:17 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 31 Jul 2007 19:18:11 +0000 Received: (qmail 24843 invoked from network); 31 Jul 2007 19:18:09 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 31 Jul 2007 19:18:09 -0000 To: Masatake YAMATO Cc: gdb-patches@sourceware.org Subject: Re: To know the stopped reason from hook-stop References: <20070731.223548.76561387.yamato@redhat.com> From: Jim Blandy Date: Tue, 31 Jul 2007 20:02:00 -0000 In-Reply-To: <20070731.223548.76561387.yamato@redhat.com> (Masatake YAMATO's message of "Tue, 31 Jul 2007 22:35:48 +0900 (JST)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-07/txt/msg00337.txt.bz2 Masatake YAMATO writes: > (I am very new to this list. > If my topic is suitable to this list, tell me the better list.) This list is fine, since you were posting a patch. Given that you're also asking broad questions about GDB's design, gdb@ would have been okay, too. > Is there way to know in hook-stop the reason why the execution > is stopped? No. :( > I could not find the way to do it, so I've just written a patch. > The patch is far from complete, but I'd like to know how to improve > it and integrate it to gdb official source tree. So I post the patch > here. Hmm. It's painful to watch people wrestle GDB's scripting language into doing something useful. If Daniel's patch to add Python as a scripting language for GDB were in the public sources, then I could say, "Don't worry about trying to fix GDB's horrible scripting language, provide this data to Python." I'm sure that's the better investment. At the same time, I don't want to make the mistake of saying, "Oh, no, let's not commit that improvement, something much better is coming along real soon now" when there are no specific plans for the much better thing's arrival. Daniel, have you had time to work on that patch since we last talked about it?