From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17277 invoked by alias); 15 Jan 2006 01:51:50 -0000 Received: (qmail 17225 invoked by uid 22791); 15 Jan 2006 01:51:49 -0000 X-Spam-Check-By: sourceware.org Received: from ns2.safetynetaccess.com (HELO r1-smtp.safetynetaccess.com) (64.61.99.3) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 15 Jan 2006 01:51:46 +0000 Received: from [10.180.0.44] (66.237.172.81.ptr.us.xo.net [66.237.172.81]) by r1-smtp.safetynetaccess.com with ESMTP id k0F1pgbq011105; Sat, 14 Jan 2006 20:51:42 -0500 (EST) Message-ID: <43C9AAA8.2030605@adacore.com> Date: Sun, 15 Jan 2006 01:51:00 -0000 From: Cyrille Comar User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 Followup-To: <20060113104212.0B28848CBD8@nile.gnat.com> To: Paul Hilfinger CC: gdb@sourceware.org Subject: : Re: [RFC] multiple breakpoints from FILE:LINE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00117.txt.bz2 >> Those menus have got to go. They're (a) confusing to users (in my >> opinion, no real data), and (b) extremely awkward for graphical >> frontends. > Interesting. As I said, in Ada, the multi-line feature is much more > important than in C. AdaCore's version has been around for years, and > has simply created multiple breakpoints (controlled by menu, as for > overloading). We haven't gotten loud calls for doing things > differently (well, point (b) has caused internal gripes), but perhaps > I should do some polling for soft grumbling from users. Ok, here is some soft grumblings from a long-standing internal user of the AdaCore version: grumble grumble... ;-) I agree with Daniel's (a) & (b). I have never grumbled before on this topic because I did not have anything constructive to contribute. This thread gave me an idea. Here it is: I believe it would be worthwhile to have 2 different break commands: - break - break-multiple (or whatever other more appropriate name) break-multiple would have the semantics advocated by Daniel (break automatically on all relevant locations) break, instead of presenting a menu, would issue an error of the kind: (gdb) break FILENAME:LINENUM multiple choices for this breakpoint, please use any of the following: break-multiple FILENAME:LINENUM break FILENAME:instance1.function:LINENUM break FILENAME:instance2.function:LINENUM break FILENAME:instance3.function:LINENUM That solves 4 issues: - an experienced user can do exactly what she wants - a less experienced user can copy/paste the appropriate choice from the error message - there is no more awkward interactive menu in text mode - a graphical interface can easily parse the error output and do whatever deemed appropriate in the interface (presenting a menu for instance)