This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] linespec.c change to stop "malformed template specification" error
Jim Blandy writes:
>
> Elena Zannoni <ezannoni@cygnus.com> writes:
> > > Operators like '<' can appear in template arguments. For example, you
> > > could define a template like this:
> > >
> > > template <int i> struct list { int a[i], b[i]; };
> > >
> > > and then use it like this:
> > >
> > > struct list <20> l;
> > >
> > > and you get the same thing as if you'd written:
> > >
> > > struct { int a[20], b[20]; } l;
> > >
> > > At least I think so, anyway. I don't really know C++. But the point
> > > is, those template arguments can be any arbitrary constant expression.
> > > So I could have a template invocation like this:
> > >
> > > struct list < (x < y) ? 10 : 20 > l;
> > >
> > > So how does our poor little decode_line_1 handle that? Basically, we
> > > need to replace decode_line_1 with a real parser.
> >
> > I am not sure that decode_line_1 will ever be invoked in such a case.
> > Looking at when it's called, it seems to be only when you specify
> > a location, not an expression, and that occurs for 'break blah' and
> > 'list blah' only.
>
> Templates can expand to functions, too:
>
Ok, I was looking at your example in a myopic way.
> template <int i>
> int add_const (int j)
> {
> return i + j;
> }
>
> then, add_const <4> (3) returns 7.
>
> But add_const <4> and add_const <5> are different functions. The
> compiler emits separate code for each of them. So you need to be able
> to set a breakpoint on add_const <4>. And the template argument to
> add_const can be any constant expression.
>
> So finding breakpoint names requires parsing (almost) arbitrary expressions.
>
Yes, you are correct. That function (find_toplevel_char) would get it wrong
if we had something like this, even with Dan's patch:
break foo_class<x>y ? 1 : 2, 4>::foo
It would think that the greater-than was the end of the template, and
that the ',' was outside of the template specification. But, if that
is a legal expression (I am not sure), how likely would it be?
Definitely better with Dan's patch than w/o, at least we can catch the
simpler cases.
Elena