From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1385 invoked by alias); 7 Apr 2010 20:21:07 -0000 Received: (qmail 1370 invoked by uid 22791); 7 Apr 2010 20:21:06 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Apr 2010 20:21:02 +0000 Received: (qmail 18098 invoked from network); 7 Apr 2010 20:21:00 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 7 Apr 2010 20:21:00 -0000 Message-ID: <4BBCE927.3070401@codesourcery.com> Date: Wed, 07 Apr 2010 20:21:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Pedro Alves CC: Stan Shebs , gdb-patches@sourceware.org Subject: Re: tracing broken if target doesn't do disconnected tracing References: <201004050101.02067.pedro@codesourcery.com> <201004071240.36873.pedro@codesourcery.com> <4BBC8981.4050900@codesourcery.com> <201004071507.18770.pedro@codesourcery.com> In-Reply-To: <201004071507.18770.pedro@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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/msg00159.txt.bz2 Pedro Alves wrote: > On Wednesday 07 April 2010 14:32:49, Stan Shebs wrote: > >> Yeah, it's been troubling me too. User-settable variables are GDB's >> traditional way of instructing GDB about user preferences, but the >> canned method of phrase construction is too lame to express what is >> really going on, which is "I prefer that targets to continue tracing >> after disconnect, whether or not the current target can actually do so". >> We could use something other than set/show, or invent a better method to >> produce output - there are other set/shows for which the verbiage is >> rather contorted. >> > > Hmm, can you expand on what lameness you're referring to exactly? > Is it a technical limitation? > It's the requirement to describe the variable with a noun phrase like "foo bar of baz", so that the output can be "foo bar of baz is on" etc. For simple settings the algorithm is reasonable, but as the concept gets more complicated, the phrasing gets more tortured. > These commands seem to fall in a close category: > > (gdb) apropos willingness > set can-use-hw-watchpoints -- Set debugger's willingness to use watchpoint hardware > set displaced-stepping -- Set debugger's willingness to use displaced stepping > show can-use-hw-watchpoints -- Show debugger's willingness to use watchpoint hardware > show displaced-stepping -- Show debugger's willingness to use displaced stepping > > Maybe we could follow suit similarly, or instead say something > like: "Show whether GDB prefers to/that/whether ..." > These are perfect examples of the same problem - "willingness" is not the right word. What these flags really mean is "use if possible", but that's a verb in an imperative form plus a conditional, and it doesn't have a direct equivalent as a noun phrase. Ideally, the "use if possible" would be augmented with "and it's possible" or "but it's not possible for reason X" so that the user can see both that the setting is as desired, and whether the debugger is able to respect it. Not a difficult extension to the command definition machinery, just have to spend some time on it. Stan