This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa] linespec.c, part 3
- From: David Carlton <carlton at math dot stanford dot edu>
- To: Klee Dienes <klee at apple dot com>
- Cc: Jim Blandy <jimb at redhat dot com>, Fernando Nasser <fnasser at redhat dot com>, Elena Zannoni <ezannoni at redhat dot com>, gdb-patches at sources dot redhat dot com
- Date: 11 Nov 2002 15:17:57 -0800
- Subject: Re: [rfa] linespec.c, part 3
- References: <35E8C110-F5C5-11D6-AA35-00039396EEB8@apple.com>
On Mon, 11 Nov 2002 17:30:41 -0500, Klee Dienes <klee@apple.com> said:
> The linespec.c changes you posted looked so cool, we couldn't resist
> using them.
Great! I would seem to have fans everywhere. :-)
> One issue that came up was that the part of our code that decodes an
> Objective-C function needs to have the if-clause removed from the
> breakpoint expression (since Objective-C functions can contain
> spaces). We did this by extending set_flags to pass back a pointer
> to the if-clause, if there was one, and by splitting decode_line_1
> into two functions, one of which sets the defaults, calls set_flags,
> strips off the if-clause and calls decode_line_2, which does the
> actual parsing.
I think that's pretty sensible. I don't care too much one way or
another as to whether or not there's a separate 'decode_line_2'
function to do the parsing, but the general idea of setting various
necessary flags first before doing any decoding sounds good to me.
For now, I want to worry about breaking up the existing code into
separate functions first (I'm already giving Elena enough to worry
about as it is, I think), but it sounds like, once that phase is done
and we can actually understand what decode_line_1 is doing, we'll want
to start rewriting functions, changing the existing reorganization.
So hold off on your patch until then, and then we can talk.
David Carlton
carlton@math.stanford.edu