This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 7/9] Explicit locations v2 - CLI for explicit locations
- From: Keith Seitz <keiths at redhat dot com>
- To: Matt Rice <ratmice at gmail dot com>
- Cc: "gdb-patches at sourceware dot org ml" <gdb-patches at sourceware dot org>
- Date: Fri, 09 May 2014 09:37:26 -0700
- Subject: Re: [RFA 7/9] Explicit locations v2 - CLI for explicit locations
- Authentication-results: sourceware.org; auth=none
- References: <536BC707 dot 4030300 at redhat dot com> <CACTLOFpYDEv0T_QQgXgLRpXk9TnwYTyfZvvda1E+uAfZdYE_4A at mail dot gmail dot com>
On 05/08/2014 05:48 PM, Matt Rice wrote:
Just curious if we need this quote handling in explicit linespec's
Good question! I did this so long ago, I'm not 100% certain /why/ I
chose to include quoting, but I can have a guess...
UI consistency. It is allowed in linespecs, largely -- but not entirely
-- to work around (old) parser problems. Users are, sadly, quite used to
quoting things. In order to maintain some sort of parallelism, I *think*
that I added the ability to quote stuff, but it is not necessary (see
below).
I thought (though i'm not terribly familiar with c++ linespecs)
that the quotes were for operator+, clashing with foo+offset
and 'something::foo' clashing with file:line stuff,
With the "new" linespec parser, I've tried to minimize the need to quote
anything. Alas, as you point out, the need still arises.
One of the tests that I have added for dprintfs seems to indicate that I
had similar concerns about permissive quoting:
(gdb) dprintf -func A::operator,,"hello\n"
Believe it or not, that actually does do what it is supposed to do. [Ok,
maybe I am the only one surprised to (re)discover that.]
where it isn't obvious to me the need for it arises when using
explicit locations.
I suppose break -source '/path with spaces/foo.c' -line +42
I tried this on my working copy:
(gdb) b -source /dir with spaces/file with spaces.c -line 3
No source file named /dir with spaces/file with spaces.c.
Make breakpoint pending on future shared library load? (y or [n]) n
So it seems I already had something in mind to handle spaces in a
relatively sane way. [Not that there aren't any lurking bugs -- I'll be
the first to admit I am seldom capable of writing bug-free code with a
patch this large.]
my main curiosity here is for languages which allow the ' character,
particularly the ML family's usage of type variables[1]. to
discriminate polymorphic functions of the variety break -function
foo('a) vs break -function foo(string).
The parser seems to already permit this syntax, but again, I'm sure
there are latent bugs in there somewhere:
(gdb) b -func foo('a)
Function "foo('a)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
So, in the end, it certainly seems that we could whack this quoting
stuff altogether if it was so desired. Other than the parallelism
`argument' that I think I used to justify this to myself when I
originally wrote it, there isn't really a compelling reason to keep it.
At least, not that I know of/remember right now.
Keith