Re: RFA: implement ambiguous linespec proposal

[Doug Evans <dje@google.com>]

On Wed, Nov 16, 2011 at 6:54 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <dje@google.com> writes:
>
> Doug> Another question while we're cleaning up linespecs, if I may.
> Doug> The docs have this:
>
> Doug> @item '@var{filename}'::@var{funcaddr}
> Doug> Like @var{funcaddr} above, but also specifies the name of the source
> Doug> file explicitly.  This is useful if the name of the function does not
> Doug> specify the function unambiguously, e.g., if there are several
> Doug> functions with identical names in different source files.
>
> Doug> Is the double colon, ::, a typo?  I've only ever seen filename
> Doug> delimited with a single colon.
>
> This form is only valid for expressions, that is, if you type
>
>    break *'file.c'::function
>
> This is a syntax extension that gdb provides.  See the 'block'
> production in c-exp.y.

Sigh. :-(

> Doug> I'm hoping we can trivially decide that a file name is present by
> Doug> seeing a single colon.
>
> In general I agree, but there are some corner cases to consider.
>
> There's the easy(-ish) corner case of DOS file names:
>
>    break c:/file.c:function
>
> There's also an Objective C case where a trailing ":" is part of the
> function name.  I forget the exact syntax, maybe it can only appear in
> brackets:
>
>    break +[method:]

I don't mind having code to catch these.
They're not normal file names.

> Anyway, like I said in the previous thread, in my view, gdb should
> require quoting for all unusual file names.  We should try to be
> compatible, but we don't have to try too awfully hard, since a lot of
> things never worked anyway.

It's not clear that the result of this is that we can programmatically
determine if a file name is present without having to go see if it's
present in the debug info.
Did you have something in mind?