From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7222 invoked by alias); 29 Aug 2011 12:15:32 -0000 Received: (qmail 7212 invoked by uid 22791); 29 Aug 2011 12:15:29 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.nokia.com (HELO mgw-da01.nokia.com) (147.243.128.24) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Aug 2011 12:15:13 +0000 Received: from gar.localnet (berwst16747.europe.nokia.com [172.25.167.47]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7TCF9iM006387; Mon, 29 Aug 2011 15:15:10 +0300 From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: ext Pedro Alves Subject: Re: [RFA] 12843 Date: Mon, 29 Aug 2011 12:15:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-30-generic; KDE/4.5.5; i686; ; ) Cc: "gdb-patches@sourceware.org" References: <4E56C5A0.60802@redhat.com> <201108290920.40589.andre.poenitz@nokia.com> <201108291112.53906.pedro@codesourcery.com> In-Reply-To: <201108291112.53906.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201108291417.02082.andre.poenitz@nokia.com> X-Nokia-AV: Clean 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-08/txt/msg00561.txt.bz2 On Monday 29 August 2011 12:12:53 ext Pedro Alves wrote: > > Just using new flags for the parameters should do the trick in this case. > > Yeah, though I expect frontends to support letting the user specify > manually where to insert the breakpoint (say, with a popup dialog > where you write foo.exe:bar or something more complicated, It's the IDE's job to capture the user's intentions, i.e. either let the user provide explicit information about the kind of the breakpoint (file and line, function, 'on throw' etc) directly in the dialog, or do the kind of linespec parsing gdb currently does (which feels pretty unnatural for a "normal" GUI user who typically does not even want to know what kind of debugging "backend" is used. But ... it looks like we look at different "frontends" here. There is a whole spectrum of "debugger frontends" from, let's say gdb/TUI, ddd etc on one end, which are essentially passing through user input more or less 1:1, requiring knowledge of exact gdb input syntax, and "IDEs" that essentially do the job of translating high level user intentions to "something that makes the backend do the right thing". A "normal" IDE user does typically not think "Hey, looks like I am on line 123 in a file called 'foo.cpp', and I know that I have a gdb backend, with version x.y or better, let's do -break-insert -f "\"foo.cpp\":123" here." He just presses or clicks. Setting a breakpoint by file name and line number covers easily 90% of all breakpoints ever set through an IDE. Unfortunately, that case is not as robust with gdb as one would wish, and the "mangling them into a single string, hoping that gdb can demangle and guess the original meaning." is part of the problem. Using individual parameters for specifying different 'aspects' would be more robust. I am really interested in the IDE case which I believe to be one intented use case for the MI protocol, and would like to ask to consider choosing a robust protocol that makes general automated interaction with gdb simple. Andre'