From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27944 invoked by alias); 7 Feb 2006 03:00:24 -0000 Received: (qmail 27932 invoked by uid 22791); 7 Feb 2006 03:00:23 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 07 Feb 2006 03:00:21 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F6J5U-000167-N9; Mon, 06 Feb 2006 22:00:16 -0500 Date: Tue, 07 Feb 2006 03:00:00 -0000 From: Daniel Jacobowitz To: Bob Rossi Cc: Markus Schiltknecht , gdb-patches@sourceware.org Subject: Re: minimalistic MI catch support Message-ID: <20060207030016.GA4152@nevyn.them.org> Mail-Followup-To: Bob Rossi , Markus Schiltknecht , gdb-patches@sourceware.org References: <1138453464.15400.9.camel@localhost.localdomain> <20060206232913.GD29510@nevyn.them.org> <20060207011600.GA18296@brasko.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060207011600.GA18296@brasko.net> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00145.txt.bz2 On Mon, Feb 06, 2006 at 08:16:01PM -0500, Bob Rossi wrote: > On Mon, Feb 06, 2006 at 06:29:13PM -0500, Daniel Jacobowitz wrote: > > For the patch, in general it's better to avoid ui_out_is_mi_like_p when > > we can. Because the text outputs are ignored in non-MI mode, this is > > usually pretty easy; see the attached. > > Daniel, could you please explain the above in more detail. In > particular, this patch adds specific functionality when in MI mode. Why > do we care about how it acts in non-MI mode? Just curious. Because it prevents the two from diverging, for one thing. It makes sure that there is no non-cosmetic output between the two. This would be useful for implementing the CLI output on top of the MI output. > Defiantly this reason is better than the original patch. I think it would be > best if we added a new enumeration called EXEC_ASYNC_CATCHPOINT_HIT, and > returned that as the reason. In the future, we could easily return the kind > of catchpoint that was caught. For instance, > > *stopped,reason="catchpoint-hit",catchpoint-kind="vfork",bkptno="1",forked-process="6570",thread-id="0",frame={addr="0x00002aaaaaeb6462",func="fork",args=[],from="/lib/libc.so.6"} I like this. > Finally, it irks me that all of the bp_catch_* commands are not being > implemented in this patch. I see these enumeration values: > bp_catch_load, > bp_catch_unload, > bp_catch_fork, > bp_catch_vfork, > bp_catch_exec, > bp_catch_catch, > bp_catch_throw > > I would really like to see a patch that supports all of these cases, or > none. It's just confusing to FE's to have 2/7'ths of the case's > implemented. > > If no one has time to do this, I will. I certainly am running thin > though. The problem with this is that some of those others are ill-defined and/or broken. Fork and vfork only work on some targets, and they're the only ones I would say worked "right". Load/unload should be implemented but aren't, exec presents very tricky user interface and symbol table problems, and catch/throw are hard to present the correct context to the user. -- Daniel Jacobowitz CodeSourcery