This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: [expr] [patch] Fix "break expr if (cond)" regression
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Keith Seitz <keiths at redhat dot com>, archer at sourceware dot org
- Date: Thu, 21 Jan 2010 14:05:22 -0700
- Subject: Re: [expr] [patch] Fix "break expr if (cond)" regression
- References: <20100121164053.GA12326@host0.dyn.jankratochvil.net>
- Reply-to: Tom Tromey <tromey at redhat dot com>
>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
Jan> I do not fully agree with my patch but I also do not fully agree
Jan> with the former patch, maybe bison should be used to parse the
Jan> expression, but rather someone (Tom? unaware) said that "break E
Jan> [thread T] [if C]" should be rather changed to the more
Jan> parseable+standardized "break [-thread T] [-if C] E" so that these
Jan> expression parsing difficulties would be present only as a backward
Jan> compatibility and do not need to supersede the former
Jan> functionality.
In the end gdb went the other route, of making "thread" special in the
lexer -- but with a twist:
/* For the same reason (breakpoint conditions), "thread N"
terminates the expression. "thread" could be an identifier, but
an identifier is never followed by a number without intervening
punctuation. "task" is similar. Handle abbreviations of these,
similarly to breakpoint.c:find_condition_and_thread. */
[...]
if (*p >= '0' && *p <= '9')
return 0;
I think linespecs would be more maintainable if we came up with a
grammar for them and implemented them using bison (or any parser
generator), but I don't know if that is even possible while preserving
compatibility.
Tom