From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20017 invoked by alias); 6 May 2003 15:16:07 -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 19986 invoked from network); 6 May 2003 15:16:06 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 6 May 2003 15:16:06 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3p2/8.9.3) with ESMTP id LAA16318 for ; Tue, 6 May 2003 11:13:24 -0400 Received: from node1.ott.qnx.com (hwlab1 [10.0.2.159]) by smtp.ott.qnx.com (8.8.8/8.6.12) with ESMTP id LAA01224 for ; Tue, 6 May 2003 11:16:04 -0400 Received: (from alain@localhost) by node1.ott.qnx.com (8.8.8/8.6.12) id LAA00824 for gdb@sources.redhat.com; Tue, 6 May 2003 11:15:58 -0400 Message-Id: <200305061515.LAA00824@node1.ott.qnx.com> Subject: Re: Catchpoint in GDB/MI To: drow@mvista.com (Daniel Jacobowitz) Date: Tue, 06 May 2003 15:16:00 -0000 From: "Alain Magloire" Cc: gdb@sources.redhat.com In-Reply-To: <20030506145944.GA27250@nevyn.them.org> from "Daniel Jacobowitz" at May 06, 2003 10:59:44 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00075.txt.bz2 > > On Tue, May 06, 2003 at 10:50:47AM -0400, Alain Magloire wrote: > > Bonjour > > > > Anyone working on putting catchpoints in GDB/MI. > > If yes what is the semantics. > > If no what is the best semantic? Completely OOB: > > > > -catch load > > ^done > > ... > > > > *stop,reason="shared-loaded",shared="libm.so" > > Do we even have any targets besides HP/UX where shared library > catchpoints _work_? Probably none, in the gdb source tree. For example, catching exceptions is probably compiler dependent 8-( .. I think. Do remember Daniel Berlin proposing a scheme for gcc long long time ago, could not retrace the email though ... darn! > We need to fix them before we talk about their MI > syntax, IMO. Similarly for most of the others. > True, but there are a lot of MI commands that are define but not implemented in the current tree or rather can not be implemented in a clean way to be submit back. So not all gdb/mi are equal depending on the distribution. But having the MI framework already in place is a good step in normalizing(sp?).