From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21529 invoked by alias); 21 Feb 2011 19:55:29 -0000 Received: (qmail 21521 invoked by uid 22791); 21 Feb 2011 19:55:29 -0000 X-SWARE-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Feb 2011 19:55:23 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 2F7E32B004; Mon, 21 Feb 2011 11:55:22 -0800 (PST) Received: from msnyder-server.eng.vmware.com (promd-2s-dhcp138.eng.vmware.com [10.20.124.138]) by mailhost3.vmware.com (Postfix) with ESMTP id 2487DCD974; Mon, 21 Feb 2011 11:55:22 -0800 (PST) Message-ID: <4D62C329.6070006@vmware.com> Date: Mon, 21 Feb 2011 20:05:00 -0000 From: Michael Snyder User-Agent: Thunderbird 2.0.0.24 (X11/20101201) MIME-Version: 1.0 To: Pedro Alves CC: "msnyder@sonic.net" , "gdb-patches@sourceware.org" Subject: Re: [RFA] info (break|watch|trace), use get_number_or_range References: <9c90ed265767e17ab56f1f865d10999d.squirrel@webmail.sonic.net> <201102202129.11630.pedro@codesourcery.com> In-Reply-To: <201102202129.11630.pedro@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2011-02/txt/msg00561.txt.bz2 Pedro Alves wrote: > On Saturday 19 February 2011 18:01:44, msnyder@sonic.net wrote: >>> This will break printing internal breakpoints, which are negative. >> AFAIK, "info break" never supported printing internal breakpoints. >> That's what "maint info break" is for. > > Sorry, I misread and though you were changing breakpoint_1, which > is the backend for "info break", "maint info break", etc. > > Doesn't this patch have the same problem I pointed out with > "info threads 1-100", in that you'll print the header once > for each breakpoint in the range? > , yes. I'll withdraw this one and try a different approach.