From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23988 invoked by alias); 10 Feb 2006 20:17:04 -0000 Received: (qmail 23979 invoked by uid 22791); 10 Feb 2006 20:17:03 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 10 Feb 2006 20:17:00 +0000 Received: from kahikatea.snap.net.nz (p202-124-114-114.snap.net.nz [202.124.114.114]) by viper.snap.net.nz (Postfix) with ESMTP id E8659745C96; Sat, 11 Feb 2006 09:16:52 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 048958887; Sat, 11 Feb 2006 09:15:58 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17388.62590.117990.323555@kahikatea.snap.net.nz> Date: Fri, 10 Feb 2006 20:17:00 -0000 To: Daniel Jacobowitz Cc: Eli Zaretskii , gdb-patches@sourceware.org Subject: Re: minimalistic MI catch support In-Reply-To: <20060210141138.GA21506@nevyn.them.org> References: <17386.57501.980555.996896@kahikatea.snap.net.nz> <17388.13240.975679.344747@kahikatea.snap.net.nz> <20060210141138.GA21506@nevyn.them.org> 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/msg00255.txt.bz2 > > > The second two have their own type: "catch fork" and "catch exec" (I > > > must admit that I don't understand how this gives differerent behaviour > > > from using "break fork" and "break exec"). > > They are associated with the system events reported for fork and exec. > That means that in addition to the above, they'll catch things like > clone with appropriate arguments, execlp, direct use of syscall()... > > Also, they give GDB external knowledge about what's going on, enabling > it to track the child of the fork, or the target of the exec. That > latter is currently disabled because the code and user interface > for following exec were such a mess. > > > > Also for some reason, they have no address. > > Unlike a breakpoint, they are associated with an event and not an > address. They aren't at all like breakpoints. OK thanks for explaining the difference. I would still say that they are a _bit_ like breakpoints (they stop execution if fork or exec are called) and I guess thats why their details are given in "info breakpoints". Are you saying "catch fork" and "catch exec" aren't at all like "catch catch" and "catch throw" which do have addresses? If so, perhaps some clearer distinction could be made to the user/in MI output. Nick