From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19799 invoked by alias); 18 Jan 2010 19:35:57 -0000 Received: (qmail 19791 invoked by uid 22791); 18 Jan 2010 19:35:56 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 18 Jan 2010 19:35:52 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o0IJZ204001905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jan 2010 14:35:02 -0500 Received: from fche.csb (vpn-232-128.phx2.redhat.com [10.3.232.128]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o0IJZ2h7028298; Mon, 18 Jan 2010 14:35:02 -0500 Received: by fche.csb (Postfix, from userid 2569) id B719C58112; Mon, 18 Jan 2010 14:35:01 -0500 (EST) To: Stan Shebs Cc: Joel Brobecker , gdb@sourceware.org Subject: Re: [RFC] "actionpoints"? References: <4B5106CB.5060204@codesourcery.com> <20100118064348.GA1914@adacore.com> <4B54AC04.7090204@codesourcery.com> From: fche@redhat.com (Frank Ch. Eigler) Date: Mon, 18 Jan 2010 19:35:00 -0000 In-Reply-To: <4B54AC04.7090204@codesourcery.com> (Stan Shebs's message of "Mon, 18 Jan 2010 10:44:20 -0800") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-01/txt/msg00161.txt.bz2 Stan Shebs writes: >>> One of the issues that has come up regularly in our tracepoint work >>> is what GDB's messages to the user should say when they are >>> referring to various combinations of tracepoints and breakpoints. > >> I like the idea of having a term that means either breakpoint/watchpoint/ >> tracepoint, etc. How about "eventpoint"? "actionpoint" sounds OK to me too. > "eventpoint" is a good candidate.k I don't have a dog in this fight, but how about plain "breakpoint" to identify any code spot or event where the target process's normal control flow is broken? In other words, make that the cover term for naming such abstract locations. Then classify into different possible breakpoint actions: "stop breakpoint", "trace breakpoint", "watch breakpoint". - FChE