On Mon, Oct 13, 2003 at 10:25:20AM -0700, Jim Ingham wrote:
I think the intent here is great!
I have a heartfelt plea, however, from one who while not as
battle-scarred as some others, have waded my way through plenty of
decode_line_1 bugs...
Is there any way we can not have to keep overloading the expression
parser with more specifications? It seems to me this is just a way to
obfuscate the user's intent so that we can get it wrong trying to
decode it later. Daniel's proposed syntax - no offense intended - is
sufficiently awful that it should give us pause. Would:
break -shlib foo.dylib -file foo.c MyStaticFunction
be all that awful? This is unambiguous, represents the user's intent
exactly, is not too hard to type, and trivial to parse. Then
internally, the breakpoint could actually hold all these separate bits
separately, rather than munging them into a canonical form which we
can
trip over later on...
We will probably have to support the specifications that we do now for
ever - though adding switches for them would allow unambiguous entry
and would probably be taken up by a good number of users cause it is
almost impossible to get wrong...
Feel free to propose a better canonical form :) You basically just
did, above. We need a canonical representation, for instance:
- We use it internally to re-place breakpoints after rereading an
objfile.
- We would like to be able to display it so that breakpoints can be
saved and reloaded.
I guess the question is whether these are useful for anything other
than specifying breakpoint (or tracepoint) locations. If not then
flags to break might be canonical enough.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer