* Re: [RFA] linespec.c change to stop "malformed template specification" error
2001-06-06 21:00 ` Jim Blandy
@ 2001-06-06 22:09 ` Daniel Berlin
2001-06-07 8:40 ` Jim Blandy
2001-06-07 8:47 ` macro-expanding expressions in GDB Jim Blandy
2001-06-06 23:36 ` [RFA] linespec.c change to stop "malformed template specification" error Daniel Berlin
` (2 subsequent siblings)
3 siblings, 2 replies; 23+ messages in thread
From: Daniel Berlin @ 2001-06-06 22:09 UTC (permalink / raw)
To: Jim Blandy; +Cc: Elena Zannoni, Daniel Berlin, gdb-patches
Jim Blandy <jimb@zwingli.cygnus.com> writes:
> Elena Zannoni <ezannoni@cygnus.com> writes:
>> Daniel Berlin writes:
>> > This error is cause by find_toplevel_char not knowing that '<' and '>'
>> > increase and decrease the depth we are at.
>> >
>> > The result is that if you say "break _Rb_tree<int, int>", when it goes
>> > to look for a comma at the top level, it thinks it found one right
>> > after the "int", and temporarily truncates the string to '_Rb_tree<int,'
>> > When we then proceed to go through the string, we see the "<", and
>> > then go to find the end of the template name, and can't, because we've
>> > truncated the string in the wrong place, and issue an error.
>> >
>> > Cute, no?
>> >
>> > --Dan
>> >
>>
>> Seems OK to me, but could you update the comment on top of the
>> find_toplevel_char() to reflect that the char is looked for also
>> outside of '<' and '>' pairs?
>>
>> Any of the other maintainers (Jim, Fernando) has any comments?
>
> 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;
Only if x and y were constant, of course.
Though i don't believe the ternary operator is allowed there, gcc
certainly doesn't like it.
You could change the example to struct list < (x < y) > l; and get the
same effect, however. I tried it just for kicks.
You'd have to be pretty f*cked up to write that though.
Especially at debug time. I could see a macro doing it, however.
>
> So how does our poor little decode_line_1 handle that? Basically, we
> need to replace decode_line_1 with a real parser.
>
> In the mean time, however, I think it's more important to recognize
> the template argument brackets at all than to handle template
> arguments that contain < and > operators.
>
> So with this caveat, I think the change is fine.
Yes, I knew this would cause problems with constant expressions,
however the solution to that without a real parser, is, of course, not
possible.
Speaking of real parsers, i've hooked up GCC's cpplib to GDB's c
expression parser if anyone is interested in the work. I'll
eventually submit it once the hooks to do the necessary gdb lookups to
handle macros are done. Neil said he'd try to have something
I also submitted patches to gcc to make it produce the dwarf2 macro
info necessary for us to let the user use macros from GDB that are
used in the source.
So this problem is only going to get worse.
If i wasn't in the middle of redoing the type system, and having it go
so well so far, i'd probably work more on replacing the decode_line_1
parser.
--
"Under my bed I have shoe box full of telephone rings. Whenever
I get lonely I open it up just a bit and I get a call. One time
I dropped the box all over the floor and the phone wouldn't stop
ringing, so I had it disconnected. I bought a new phone though.
I didn't have much money so I had to buy an irregular phone --
it had no number 5 on it. I saw a close friend of mine the
other day... He said, "Steven, why haven't you called me?" I
said, "I can't call everyone I want. My new phone has no five
on it." He said, "How long have you had it?" I said, "I don't
know... My calendar has no sevens on it."
"-Steven Wright
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [RFA] linespec.c change to stop "malformed template specification" error
2001-06-06 22:09 ` Daniel Berlin
@ 2001-06-07 8:40 ` Jim Blandy
2001-06-07 8:47 ` macro-expanding expressions in GDB Jim Blandy
1 sibling, 0 replies; 23+ messages in thread
From: Jim Blandy @ 2001-06-07 8:40 UTC (permalink / raw)
To: Daniel Berlin; +Cc: Elena Zannoni, gdb-patches
Daniel Berlin <dan@cgsoftware.com> writes:
> Though i don't believe the ternary operator is allowed there, gcc
> certainly doesn't like it.
It should be. It's a constant expression in C, anyway. And it would
seem to be under Stroustrup's (rather hand-wavy) Section C.5, too.
^ permalink raw reply [flat|nested] 23+ messages in thread
* macro-expanding expressions in GDB
2001-06-06 22:09 ` Daniel Berlin
2001-06-07 8:40 ` Jim Blandy
@ 2001-06-07 8:47 ` Jim Blandy
2001-06-07 9:01 ` Daniel Berlin
2001-06-07 11:16 ` Stan Shebs
1 sibling, 2 replies; 23+ messages in thread
From: Jim Blandy @ 2001-06-07 8:47 UTC (permalink / raw)
To: Daniel Berlin; +Cc: gdb-patches
Daniel Berlin <dan@cgsoftware.com> writes:
> Speaking of real parsers, i've hooked up GCC's cpplib to GDB's c
> expression parser if anyone is interested in the work. I'll
> eventually submit it once the hooks to do the necessary gdb lookups to
> handle macros are done. Neil said he'd try to have something
This is a feature to die for. Fantastic.
I have two concerns about using cpplib:
- I don't want GDB builds to require the GCC sources around. This is
mostly bureacracy --- we'd need to have cpplib moved into its own
top-level directory, so we could share it with GCC.
- I wonder how much of cpplib we actually need. We don't need
#includes, #ifs, or CPP expression evaluation. cpplib seems
heavyweight. This is somewhat nitpicky.
Sorry, which Niel? If I can find the bandwidth, I'd love to do the
symbol table support for this.
> I also submitted patches to gcc to make it produce the dwarf2 macro
> info necessary for us to let the user use macros from GDB that are
> used in the source.
And we don't even need to wait for that. We can add the macro info to
the .s files manually, and test against those files.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: macro-expanding expressions in GDB
2001-06-07 8:47 ` macro-expanding expressions in GDB Jim Blandy
@ 2001-06-07 9:01 ` Daniel Berlin
2001-06-07 11:52 ` Jim Blandy
2001-06-07 11:16 ` Stan Shebs
1 sibling, 1 reply; 23+ messages in thread
From: Daniel Berlin @ 2001-06-07 9:01 UTC (permalink / raw)
To: Jim Blandy; +Cc: Daniel Berlin, gdb-patches
Jim Blandy <jimb@zwingli.cygnus.com> writes:
> Daniel Berlin <dan@cgsoftware.com> writes:
>> Speaking of real parsers, i've hooked up GCC's cpplib to GDB's c
>> expression parser if anyone is interested in the work. I'll
>> eventually submit it once the hooks to do the necessary gdb lookups to
>> handle macros are done. Neil said he'd try to have something
>
> This is a feature to die for. Fantastic.
>
> I have two concerns about using cpplib:
> - I don't want GDB builds to require the GCC sources around. This is
> mostly bureacracy --- we'd need to have cpplib moved into its own
> top-level directory, so we could share it with GCC.
I was going to bring this up right after gcc 3.0. Everyone is running
around fixing high priority bugs, doing more documentation work, etc,
preparing for the June 15th release, so it would get ignored until
then.
> - I wonder how much of cpplib we actually need. We don't need
> #includes, #ifs, or CPP expression evaluation. cpplib seems
> heavyweight. This is somewhat nitpicky.
Then again, IIRC, Stan Shebs and Apple were interested in using cpplib
to fake the dwarf2 macro info we get (IE parse the actual files to
produce the same type of info).
It's not as difficult as one would think to do this, actually, but
it's still a pain in the ass (especially since it requires all the
source files around).
>
> Sorry, which Niel?
Neil Booth <neil@daikokuya.demon.co.uk> (or so BBDB tells me).
He's one of the two people who *really* understands and maintains
cpplib.
> If I can find the bandwidth, I'd love to do the
> symbol table support for this.
I've actually already done it, I can post it if you like.
Macros live in the MACRO_NAMESPACE.
Each macro's name is it's symbol name.
The text of the macro is the symbol's value.
The hardest part was actually getting the macros into the right
blocks, as you would imagine.
The callback i'm referring to is the fact that we need cpplib to
provide a callback when it goes to determine if something is a macro
or not. That way, we can look it up in gdb's symbol table instead. Right
now, it looks it up in it's internal symbol table. This will of
course, never find it. The other ways around this (not using a
callback) are so hairy it's not even funny. There was a discussion
about it on the gcc list.
>
>> I also submitted patches to gcc to make it produce the dwarf2 macro
>> info necessary for us to let the user use macros from GDB that are
>> used in the source.
>
> And we don't even need to wait for that. We can add the macro info to
> the .s files manually, and test against those files.
Right.
--
"I can remember the first time I had to go to sleep. Mom said,
"Steven, time to go to sleep." I said, "But I don't know how."
She said, "It's real easy. Just go down to the end of tired and
hang a left." So I went down to the end of tired, and just out
of curiosity I hung a right. My mother was there, and she said
"I thought I told you to go to sleep."
"-Steven Wright
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: macro-expanding expressions in GDB
2001-06-07 9:01 ` Daniel Berlin
@ 2001-06-07 11:52 ` Jim Blandy
2001-06-07 12:04 ` Daniel Berlin
0 siblings, 1 reply; 23+ messages in thread
From: Jim Blandy @ 2001-06-07 11:52 UTC (permalink / raw)
To: Daniel Berlin; +Cc: gdb-patches
Daniel Berlin <dan@cgsoftware.com> writes:
> I've actually already done it, I can post it if you like.
>
> Macros live in the MACRO_NAMESPACE.
> Each macro's name is it's symbol name.
> The text of the macro is the symbol's value.
>
> The hardest part was actually getting the macros into the right
> blocks, as you would imagine.
Yeah. I guess I don't see the point in trying to fit them into the
existing symbol table structure:
- Macros aren't scoped in a block-structured fashion; they have ranges
of lines over which they're in force. So the block tree is a total
misfit for them.
- They don't have addresses or types, so the fields of struct symbol
are mostly garbage.
- Struct symbol doesn't have anyplace really appropriate to store
an argument list.
I would want them in a separate structure that can accurately
represent their behavior.
Ideally, given an object code location, I want to be able to find the
definitions that were in force when that object code was emitted.
Unfortunately, we can't do this perfectly; if a file is #included more
than once, perhaps with different #definitions in force each time,
that control #if directives that establish different definitions for
other macros, no debugging format (including Dwarf 2) provides enough
information for us to tell which #inclusion corresponds to which code
address. Dwarf 2's macro information does it right, but its text
address <-> source location mapping doesn't.
> The callback i'm referring to is the fact that we need cpplib to
> provide a callback when it goes to determine if something is a macro
> or not. That way, we can look it up in gdb's symbol table instead. Right
> now, it looks it up in it's internal symbol table. This will of
> course, never find it. The other ways around this (not using a
> callback) are so hairy it's not even funny. There was a discussion
> about it on the gcc list.
Yeah, to be useful to GDB, cpplib's expansion code needs to be
decoupled from the rest of the CPP stuff --- and that includes the
code for #define, which establishes the definitions in the first place.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: macro-expanding expressions in GDB
2001-06-07 11:52 ` Jim Blandy
@ 2001-06-07 12:04 ` Daniel Berlin
0 siblings, 0 replies; 23+ messages in thread
From: Daniel Berlin @ 2001-06-07 12:04 UTC (permalink / raw)
To: Jim Blandy; +Cc: Daniel Berlin, gdb-patches
Jim Blandy <jimb@zwingli.cygnus.com> writes:
> Daniel Berlin <dan@cgsoftware.com> writes:
>> I've actually already done it, I can post it if you like.
>>
>> Macros live in the MACRO_NAMESPACE.
>> Each macro's name is it's symbol name.
>> The text of the macro is the symbol's value.
>>
>> The hardest part was actually getting the macros into the right
>> blocks, as you would imagine.
>
> Yeah. I guess I don't see the point in trying to fit them into the
> existing symbol table structure:
>
> - Macros aren't scoped in a block-structured fashion; they have ranges
> of lines over which they're in force. So the block tree is a total
> misfit for them.
Right.
>
> - They don't have addresses or types, so the fields of struct symbol
> are mostly garbage.
>
Right.
> - Struct symbol doesn't have anyplace really appropriate to store
> an argument list.
Right again.
>
> I would want them in a separate structure that can accurately
> represent their behavior.
I had them there, then i changed it.
I'll change it back.
>
> Ideally, given an object code location, I want to be able to find the
> definitions that were in force when that object code was emitted.
> Unfortunately, we can't do this perfectly; if a file is #included more
> than once, perhaps with different #definitions in force each time,
> that control #if directives that establish different definitions for
> other macros, no debugging format (including Dwarf 2) provides enough
> information for us to tell which #inclusion corresponds to which code
> address. Dwarf 2's macro information does it right, but its text
> address <-> source location mapping doesn't.
Right. Well, yet, anyway.
There is an accepted proposal for discontiguous scopes, which may let
you do this, actually (even though that's not it's real intention).
The best we can do right now is take the PC you give us, find the
closest line, and tell you what macros were in force at that *line*.
And we can do this perfectly, actually.
>
>> The callback i'm referring to is the fact that we need cpplib to
>> provide a callback when it goes to determine if something is a macro
>> or not. That way, we can look it up in gdb's symbol table instead. Right
>> now, it looks it up in it's internal symbol table. This will of
>> course, never find it. The other ways around this (not using a
>> callback) are so hairy it's not even funny. There was a discussion
>> about it on the gcc list.
>
> Yeah, to be useful to GDB, cpplib's expansion code needs to be
> decoupled from the rest of the CPP stuff --- and that includes the
> code for #define, which establishes the definitions in the first
> place.
This isn't possible/genreally considered a bad idea.
We had this discussion on the gcc list a few weeks ago, i asked for
the very same thing.
Everyone told me this was a bad idea.
:)
--
"My neighbor has a circular driveway... He can't get out.
"-Steven Wright
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: macro-expanding expressions in GDB
2001-06-07 8:47 ` macro-expanding expressions in GDB Jim Blandy
2001-06-07 9:01 ` Daniel Berlin
@ 2001-06-07 11:16 ` Stan Shebs
1 sibling, 0 replies; 23+ messages in thread
From: Stan Shebs @ 2001-06-07 11:16 UTC (permalink / raw)
To: Jim Blandy; +Cc: Daniel Berlin, gdb-patches
Jim Blandy wrote:
>
> Daniel Berlin <dan@cgsoftware.com> writes:
> > Speaking of real parsers, i've hooked up GCC's cpplib to GDB's c
> > expression parser if anyone is interested in the work. I'll
> > eventually submit it once the hooks to do the necessary gdb lookups to
> > handle macros are done. Neil said he'd try to have something
>
> This is a feature to die for. Fantastic.
Amen. If I didn't have so many Apple-specific *&^%#$@! patches to
deal with, I'd want to be having fun with this.
> I have two concerns about using cpplib:
> - I don't want GDB builds to require the GCC sources around. This is
> mostly bureacracy --- we'd need to have cpplib moved into its own
> top-level directory, so we could share it with GCC.
Presumably it can be handled similarly to libiberty, with two
copies, and on-demand resyncing. Since GDB only needs the subset
functionality, it can probably be a little behind without causing
any problems.
> - I wonder how much of cpplib we actually need. We don't need
> #includes, #ifs, or CPP expression evaluation. cpplib seems
> heavyweight. This is somewhat nitpicky.
It's true that cppmacro.c is only about 10% of the cpplib sources,
but in practice it seems like a lot of trouble to further partition
cpplib. GDB doesn't use all of BFD either, but who wants to go to
the trouble of partitioning it into a reading-only part?
> Sorry, which Niel?
That's Neil Booth.
Stan
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFA] linespec.c change to stop "malformed template specification" error
2001-06-06 21:00 ` Jim Blandy
2001-06-06 22:09 ` Daniel Berlin
@ 2001-06-06 23:36 ` Daniel Berlin
2001-06-07 6:00 ` Fernando Nasser
2001-06-07 7:40 ` Elena Zannoni
3 siblings, 0 replies; 23+ messages in thread
From: Daniel Berlin @ 2001-06-06 23:36 UTC (permalink / raw)
To: Jim Blandy; +Cc: Elena Zannoni, Daniel Berlin, gdb-patches
Jim Blandy <jimb@zwingli.cygnus.com> writes:
> Elena Zannoni <ezannoni@cygnus.com> writes:
>> Daniel Berlin writes:
>> > This error is cause by find_toplevel_char not knowing that '<' and '>'
>> > increase and decrease the depth we are at.
>> >
>> > The result is that if you say "break _Rb_tree<int, int>", when it goes
>> > to look for a comma at the top level, it thinks it found one right
>> > after the "int", and temporarily truncates the string to '_Rb_tree<int,'
>> > When we then proceed to go through the string, we see the "<", and
>> > then go to find the end of the template name, and can't, because we've
>> > truncated the string in the wrong place, and issue an error.
>> >
>> > Cute, no?
>> >
>> > --Dan
>> >
>>
>> Seems OK to me, but could you update the comment on top of the
>> find_toplevel_char() to reflect that the char is looked for also
>> outside of '<' and '>' pairs?
>>
>> Any of the other maintainers (Jim, Fernando) has any comments?
>
> 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.
Wait, stop, this is a complete red herring.
It's irrelevant.
decode_line_1 is used in breakpoints and listing (break and list). *NOT* in
an expression like "p a<5 < 6>"
An decode_line_1 says the string can be:
"LINENUM
FILENAME:LINENUM
FUNCTION
VARIABLE
FILE:FUNCTION
*EXPR"
Since we don't give a shit what the actual arguments to the template
specification are (you can't very well expect us to *evaluate* them in
this context, we certainly don't now), you end up with a grammar like i'm about
to show, excluding *EXPR, which you just special case, as we do
now. This grammar appears to work fine.
The reason COLONCOLON and COLON are seperate from the rest of the
allowed characters is only because double colon is part of a function
name, colon isn't.
Pretend we did symbol lookup along the way, rather than at the end, as
we do now.
%token IDENT
%token NUM
%token COLONCOLON
%token COLON
%%
input : line_reference
| function_name;
line_reference: NUM
| IDENT COLON NUM;
function_name:
IDENT COLON function_name /* function name with filename in front */
| IDENT COLONCOLON function_name /* scoped function name of some sort*/
| IDENT; /* just a name of some sort */
Now, two things.
One:
IDENT here is [a-zA-Z][A-Za-z0-9<>, ]*
This means daniel<int>::fred is a function name.
As is daniel<int bob, int fred>::george
Two:
Realize the fact that this grammar accepts "DANIEL<int>::fred:fred" is
irrelevant. We'll never find a match for it, and alert the user to
it.
Same with the fact that you could put DANIEL<int::5
We'll never find DANIEL<int, and point it out to you when we failed to
find it.
Same if you start making up invalid template arguments (daniel<int int
int int int>::fred. We'll fail the first lookup, and point it out).
No shift-reduce conflicts, BTW, because of the proper placement of
function_name (function_name COLONCOLON IDENT would give you one, for
instance).
The only thing doing symbol evaluation along the way buys us is better
error messages (well, less painful, better, error messages. we could
still do it without symbol evaluation along the way, it's just a pain
in the ass to track the same info, and we'd likely point to the wrong
thing as the real error).
The tricky part of it is deferring an error message on scoped names
(IE till we've failed all the possibility) until the very end, or something like that.
We could just do what we effectively do now, defer decoding a function name till
the parse is done, and deal with it then.
I've got this all flex and bisonified (as you can tell from the above)
up already, and it works, if you guys think i should submit it.
--Dan
>
> In the mean time, however, I think it's more important to recognize
> the template argument brackets at all than to handle template
> arguments that contain < and > operators.
>
> So with this caveat, I think the change is fine.
--
"I lost a button hole today. Where am I gonna find another one?
"-Steven Wright
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: [RFA] linespec.c change to stop "malformed template specification" error
2001-06-06 21:00 ` Jim Blandy
2001-06-06 22:09 ` Daniel Berlin
2001-06-06 23:36 ` [RFA] linespec.c change to stop "malformed template specification" error Daniel Berlin
@ 2001-06-07 6:00 ` Fernando Nasser
2001-06-07 9:09 ` Jim Blandy
2001-06-07 7:40 ` Elena Zannoni
3 siblings, 1 reply; 23+ messages in thread
From: Fernando Nasser @ 2001-06-07 6:00 UTC (permalink / raw)
To: Jim Blandy; +Cc: Elena Zannoni, Daniel Berlin, gdb-patches
Jim Blandy wrote:
>
> So how does our poor little decode_line_1 handle that? Basically, we
> need to replace decode_line_1 with a real parser.
>
It will be hard. As it accepts a variety of types of input, there are
ambiguities in the allowed syntax that are hard to describe in any
formal language.
What I am trying to say is that, although the current implementation may
be lame, the problem is more fundamental -- it is the concept of
linespec itself with the "accept anything with any system variant and
language variant from function names to filenames and line numbers and
combinations thereof".
With this search space, I guess the heuristic method that exists today
became the only one that was feasible to implement.
Maybe we could improve things if GDB commands were parsed under some
language context (e.g. care about C++ stuff or not) and even some host
context (to distinguish filename syntaxes between Unix and Windows for
instance).
Cheers,
Fernando
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFA] linespec.c change to stop "malformed template specification" error
2001-06-07 6:00 ` Fernando Nasser
@ 2001-06-07 9:09 ` Jim Blandy
0 siblings, 0 replies; 23+ messages in thread
From: Jim Blandy @ 2001-06-07 9:09 UTC (permalink / raw)
To: Fernando Nasser; +Cc: Elena Zannoni, Daniel Berlin, gdb-patches
Fernando Nasser <fnasser@redhat.com> writes:
> Jim Blandy wrote:
> > So how does our poor little decode_line_1 handle that? Basically, we
> > need to replace decode_line_1 with a real parser.
>
> It will be hard. As it accepts a variety of types of input, there are
> ambiguities in the allowed syntax that are hard to describe in any
> formal language.
Don't worry about producing a grammar Bison would like. We can write
N parsers, some of them Bison-based, some of them hand-coded, but each
one which handles a single case correctly and cleanly. Then, we can
invoke them each in turn, and use the result from the first one which
doesn't return an error. The C, C++, and other language parsers would
just be members of the list.
> Maybe we could improve things if GDB commands were parsed under some
> language context (e.g. care about C++ stuff or not) and even some
> host context (to distinguish filename syntaxes between Unix and
> Windows for instance).
Well, language is a per-compilation-unit kind of thing. And the user
should just be able to say "break foo^..bratwurst" whenever
foo^..bratwurst is a well-defined breakpoint location, even if it's
not in the current compilation unit.
There's even a trick we can use to get our existing parsers to work
for this. We don't need to write new grammars.
Right now, the start symbol for our C++ grammar is `start', which is
either an expression or a type. Suppose we want to parse expressions,
types, and function names. We make up three new magic token types:
START_EXPRESSION, START_TYPE, and START_FUNCTION_NAME. We change the
syntax of our start symbol to be:
start : START_EXPRESSION exp1
| START_TYPE type_exp
| START_FUNCTION_NAME function_name
;
(I don't think function_name exists yet, but that work is necessary no
matter how we do this.)
Then, we change our yylex function to return START_EXPRESSION,
START_TYPE, or START_FUNCTION_NAME as the first token, depending on
which one we want to parse. These tokens don't correspond to
anything in the text stream at all --- they just serve to get the
parser in the right state to recognize what we're giving it.
But to be clear, we do *not* need to encode the full glory of
breakpoint locations here. We extend the grammar to handle what it
can do naturally --- probably just template applications and
overloading.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [RFA] linespec.c change to stop "malformed template specification" error
2001-06-06 21:00 ` Jim Blandy
` (2 preceding siblings ...)
2001-06-07 6:00 ` Fernando Nasser
@ 2001-06-07 7:40 ` Elena Zannoni
[not found] ` <nppucg1eq5.fsf@zwingli.cygnus.com>
3 siblings, 1 reply; 23+ messages in thread
From: Elena Zannoni @ 2001-06-07 7:40 UTC (permalink / raw)
To: Jim Blandy; +Cc: Elena Zannoni, Daniel Berlin, gdb-patches
Jim Blandy writes:
>
> Elena Zannoni <ezannoni@cygnus.com> writes:
> > Daniel Berlin writes:
> > > This error is cause by find_toplevel_char not knowing that '<' and '>'
> > > increase and decrease the depth we are at.
> > >
> > > The result is that if you say "break _Rb_tree<int, int>", when it goes
> > > to look for a comma at the top level, it thinks it found one right
> > > after the "int", and temporarily truncates the string to '_Rb_tree<int,'
> > > When we then proceed to go through the string, we see the "<", and
> > > then go to find the end of the template name, and can't, because we've
> > > truncated the string in the wrong place, and issue an error.
> > >
> > > Cute, no?
> > >
> > > --Dan
> > >
> >
> > Seems OK to me, but could you update the comment on top of the
> > find_toplevel_char() to reflect that the char is looked for also
> > outside of '<' and '>' pairs?
> >
> > Any of the other maintainers (Jim, Fernando) has any comments?
>
> 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. Also, find_toplevel_char is called only when looking
for a comma, so even with your example it should still work fine,
even though the 'depth' variable will have an inaccurate value.
But yes, I agree, decode_line_1 is a mess.
Elena
>
> In the mean time, however, I think it's more important to recognize
> the template argument brackets at all than to handle template
> arguments that contain < and > operators.
>
> So with this caveat, I think the change is fine.
>
^ permalink raw reply [flat|nested] 23+ messages in thread