Unambiguously specifying source locations

[Jim Ingham]

So one corollary that makes this easier is that instead of holding onto 
the requested shared library (and requested file for static functions) 
in the address string, we should hold them in the breakpoint structure 
itself.  So then we don't have to worry about what the canonical form 
is.  That too becomes simple, it is:

b->requested_filename = "myFile.c"
b->requested_shlib = "myShlib.dylib"

And if there are any others, we can add them.  So we only have to break 
out the specifications when the user instructs us to set the 
breakpoint.  After that all the bits are clear.

I started playing around with this for dylibs for purposes of my own... 
  I called them requested_* because I wanted to make it clear that these 
were not where we found the thing, but where the user asked for the 
thing.  It is also interesting where the breakpoint eventually landed, 
but that bit should be in the "implementation" side of the breakpoint.  
This clearly belongs in the user side...

Jim


On Oct 14, 2003, at 4:06 PM, gdb-digest-help@sources.redhat.com wrote:

>
>
> 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
>
>
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer