From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13275 invoked by alias); 15 Feb 2012 09:27:01 -0000 Received: (qmail 13266 invoked by uid 22791); 15 Feb 2012 09:27:00 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI X-Spam-Check-By: sourceware.org Received: from mailgw10.se.ericsson.net (HELO mailgw10.se.ericsson.net) (193.180.251.61) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 15 Feb 2012 09:26:46 +0000 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C4.02.01970.35A7B3F4; Wed, 15 Feb 2012 10:26:43 +0100 (CET) Received: from esekilx5037.rnd.ki.sw.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Wed, 15 Feb 2012 10:26:43 +0100 Message-ID: <4F3B7A53.7080509@ericsson.com> Date: Wed, 15 Feb 2012 09:48:00 -0000 From: =?ISO-8859-1?Q?Tomas_=D6stlund?= User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Pedro Alves CC: "gdb-patches@sourceware.org" , ERAMMFN , Subject: Re: [RFC/WIP PATCH 00/14] I/T sets (resend) References: <20111128153742.17761.21459.stgit@localhost6.localdomain6> <4F338167.3020201@ericsson.com> <4F33D9BD.7020209@redhat.com> In-Reply-To: <4F33D9BD.7020209@redhat.com> Content-Type: text/plain; charset="ISO-8859-1" 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: 2012-02/txt/msg00295.txt.bz2 On 02/09/12 15:35, Pedro Alves wrote: [...] > > Great. I actually implemented most of this. > > See the v2 (latest version) of the series at: > > http://sourceware.org/ml/gdb-patches/2011-12/msg00550.html Thanks, I will check that out. > > The problem is one of ambiguity when you want to be able to specify > sets as an option, and support other options. E.g., > > break -stop foo bar qux > > -stop takes a set as argument. Is the set "foo", or "foo bar"? Perhaps > even "foo bar qux"? You'd need to quote the set somehow, like > > break -stop 'foo bar' qux. > > which we were trying to avoid (just like []'s) > > We could allow optional quoting. Another alternative would be to use some > other characters. I don't know, '.', and ',' seemed quite intuitive to me. Maybe > you could try v2 out a bit. It's still easily accessible in my git, as pointed > out in the v2 series intro. I'm not sure I see what the problem is here. If you compare to a UNIX shell, you have the same kind of issue that you sometimes need to quote in order to be unambiguous. For example, using the grep command as an example: > grep foo bar froz will grep for the string "foo" in the files bar and froz. On the other hand, in order to search for the string "foo bar" in the file froz you need to quote like > grep "foo bar" froz. The idea is that you do not need to *always* quote as was the case with the brackets in the HPD spec, only when the command is ambiguous. So I think it is perfectly fine to expect the user to somehow quote the argument to the -stop flag like break -stop 'foo bar' qux or break -stop foo,bar qux > > It kind of follows from the idea that you can also switch the > set focus permanently. With "itfocus" in v1, or "scope" in v2. > > You define your commands to apply to the current > scope. So: > > (gdb) itfocus foo / scope foo > (gdb) step > > is the same as > > (gdb) [foo] step (v1) > > or > > (gdb) scope foo step (v2) > > IOW, you can think of prefix scope as a shorthand. BTW, the v2 syntax is > quite like TotalView's (they call theirs "dfocus", IIRC). I think the semantics of this is confusing. The command "scope foo" and "scope foo step" looks quite similar but has completely different semantics. If you compare again with a UNIX shell (which I think is a very good analogy and one that maps very well to the PCT concept)it would mean that you would write > cd bar ls instead of simply > ls bar As you can see, I like the semantics of the Unix shell ;-) The reason I use the shell as example is that our debugger shell is very much influenced by it and as I said, it maps very nicely. Both the UNIX shell and a debugger shell has a concept of a "current context". In the UNIX shell, it is the current working directory and in the debug shell it is the "current working set". In the Unix shell many commands operates on files and directories and in the debug shell it operates on cores, processes and threads. We have even implemented shell things like ";" to execute more than one command like cluster1/dsp0> step; print foo; go; print bar will step the current core dsp0, then print the variable foo, then start execution and finally print the variable bar when we stop for some reason. Another shell features we have is redirect of output, so that you can write things like cluster1/dsp0> showregisters > my_regs.txt The above command will store the contents of all registers on dsp0 in the file my_reg.txt. The nice thing about mimicking a real shell is that you have a lot of knowledge that can be directly transferred to the debug shell. If you know how to use a UNIX shell then many of the same concepts can be reused. Cheers, Tomas