[PATCH] python/19506 -- gdb.Breakpoint address location regression

[Keith Seitz]

On 01/26/2016 04:22 AM, Joel Brobecker wrote:
> Silly question, but does this work with " *main" (extra leading
> space)?

A very valid question, in fact. Answer: It works *now*! ;-)

> It's too bad you have to explicitly check for '*' in the string.
> Perhaps we should delegate that part to the linespec module?
> Perhaps other areas might want to have the same (eg. the guile
> breakpoint module).

[Apologies for waxing a little philosophical here...]

Here we are again with the same question as last time: should address
locations be considered during linespec parsing? To be honest, I keep
bouncing back and forth on this (a bit).

IMO we have two opposing "forces" involved in this decision:
1) Ease of use
2) Separation of APIs

For me, #1 really boils down to UI writers "passing the buck" down to
gdb's internals (via CLI generalisms). With the location API work, I
tried to make this layer a little more distinct/separate. UIs are
responsible for implementing their own representations of locations in a
way most consistent with their implementation specifics. [Example: using
'gdb.Breakpoint("-source foo.c -line 3")' seems downright wrong to me.]

The CLI representation is well known, and since we already had a
"parser" for it, MI, Python, and Guile just followed suit, reusing the
syntax. Hey, it was easy! [And there is *nothing* wrong with that decision.]

#2 is really just a theoretical concept. It isn't strictly necessary,
but it sure would be nice to have [YMMV]. While I like encapsulating
small(er) bits of separate functionality into separate APIs, it
sometimes seems more work than it is worth.

However, I think there is a trade-off here that can maintain (much of)
both of these desirable traits.  I missed that when I implemented the
locations patches.

I failed to acknowledge that we have this legacy "re-using" of CLI
idioms like linespecs, and I should have made concessions to facilitate
re-using this "legacy" syntax. [I say "legacy" to mean pre-locations
linespecs compared to today's linespec location. An unfortunately subtle
choice of words, I know.]

In light of this, I am suggesting that instead of requiring
python/mi/guile/whatever to implement their own string_to_event_location
functions, that the current string_to_event_location be split into a
"legacy" portion (that deals with address, probe, and linespec
locations) and a newer (and separate) explicit-handling form (for the
CLI only).

This leaves python/guile to implement an explicit location specification
in a manner more consistent with those interpreters, e.g., python could
use named arguments to gdb.Breakpoint:

  gdb.Breakpoint(source="foo.c", line="3")

This way we wouldn't "force" these languages to use the CLI's
argument/value paradigm. I've already done something similar for MI. [MI
is currently using string_to_event_location, which means it will
erroneously support the CLI's explicit syntax in addition to its own!
Bug! My bad! Have patch.]

In short:
1) Remove explicit locations from string_to_event_location.
   Use this "new" function /everywhere/ legacy linespec support is
   desired. In my working tree, I call this
   string_to_event_location_basic.
2) string_to_event_locations can now be refactored to do two things:
   check for an explicit location OR call the _basic version to deal
   with linespec, address, and probe locations.

WDYT? [I can send a small patch series to address/clean up all of these,
if you think this is a reasonable resolution.]

Keith