From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12964 invoked by alias); 8 Apr 2010 23:26:02 -0000 Received: (qmail 12955 invoked by uid 22791); 8 Apr 2010 23:26:02 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 08 Apr 2010 23:25:58 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 8A8CA2BABEF; Thu, 8 Apr 2010 19:25:56 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5qawkXXvOdLj; Thu, 8 Apr 2010 19:25:56 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 4C7C42BABE4; Thu, 8 Apr 2010 19:25:56 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 9E72CF58C2; Thu, 8 Apr 2010 16:25:47 -0700 (PDT) Date: Thu, 08 Apr 2010 23:26:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org, Phil Muldoon , Tom Tromey , Eli Zaretskii Subject: Re: [patch][python] Add breakpoint support. Message-ID: <20100408232547.GN19194@adacore.com> References: <4BB0B063.6000600@redhat.com> <4BBE4A34.3020301@redhat.com> <20100408214455.GM19194@adacore.com> <201004082321.01822.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201004082321.01822.pedro@codesourcery.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-04/txt/msg00210.txt.bz2 > I'd just like to point out that we already have code in the tree (and > for a decade) that dumps tracepoints into a file; the file can be > sourced as a cli script afterwards. See breakpoint.c:tracepoint_save_command. > Since the tracepoint/breakpoints merge, it is trivial to extend that function > to dump breakpoints as well. I almost did implement things that way, and it's certainly better than nothing. Maybe I'm letting best be the enemy of good, but there are issues with a pure CLI script approach that a user cannot control. For instance, what if one of the breakpoints now fails? A CLI script would abort early, leaving some of the breakpoints not restored. If some of the breakpoints were in DSOs that only get loaded at runtime, should they be created as pending? I can't remember what the default is when from_tty is not set... I like the python approach because it allows us to provide a more configurable approach than a pure CLI script would give us. -- Joel