This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Unambiguously specifying source locations
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: gdb at sources dot redhat dot com
- Date: Mon, 13 Oct 2003 13:32:38 -0400
- Subject: Re: Unambiguously specifying source locations
- References: <1065875539.13549.ezmlm@sources.redhat.com> <38B36630-FDA2-11D7-BB88-000A958F4C44@apple.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