Re: Unambiguously specifying source locations

[Daniel Jacobowitz <drow at mvista dot com>]

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