public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
* update on ambiguous linespec branch
@ 2011-08-25 20:53 Tom Tromey
  2011-08-26  1:41 ` [Archer] " Joel Brobecker
  2011-08-26  1:45 ` Tom Tromey
  0 siblings, 2 replies; 4+ messages in thread
From: Tom Tromey @ 2011-08-25 20:53 UTC (permalink / raw)
  To: Project Archer

I'm taking some time off soon, and I wanted to send out an update about
the state of my branch before disappearing.

The project is to implement the "ambiguous linespec" proposal as
discussed on gdb-patches.  The branch is
archer-tromey-ambiguous-linespec.  There is a tracking bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=13105 It depends on all
the bugs that I think will be fixed; in fact most of them are already
fixed on the branch.

Right now most of the new functionality is implemented on the branch.
Nearly all of the work is in linespec, with a little spilling over into
breakpoint.c.  Most of the work was changing linespec to iterate instead
of being satisfied with a single successful lookup.

Here's my remaining to-do list.  I will work on it before my break, but
probably won't finish it.

* I totally broke ranged breakpoints, in fact I #if'd out some of the
  code as a temporary hack.

  It isn't clear to me how ranged breakpoints should actually work if
  there are multiple matches.  Any thoughts?

  One idea I had was to have break-range give an error if the first
  linespec has multiple matches (perhaps defaulting to
  multiple-symbols=ask for this code), then when resolving the second
  linespec, pick the SAL whose PC is closest (but still greater than)
  the PC in the first linespec.

  This may not work supremely well when re-setting, though, since that
  can cause multiple matches when there were none before.

  Also, as an aside, if someone has a use case for break-range, I'm
  curious to know what it is.  I couldn't think of when I would use it.

* Documentation updates.

* I didn't yet implement the new linespec types, namely allowing
  "OBJFILE:" as a prefix, or "FILE:FUNCTION:LINE" or
  "FILE:FUNCTION:LABEL".

  I have an idea that we can do this by breaking the linespec up into
  tokens before trying to figure out what the tokens mean, consolidating
  a lot of the lexing logic.  (Which I think is one of the main ugly
  things in linespec.)

  I don't think this item is really needed for the patch to go in.  It
  could be done as a follow-up, and IMO would be better that way, since
  it will be a second huge change to linespec.c.

* struct breakpoint should drop the pspace and gdbarch fields.
  It seems possible to do, though it is hard to be completely sure.

* Audit all the other linespec callers to make sure they are doing the
  right thing.  I think in many cases this will mean using
  multiple-symbols=ask.  However, this is slightly weird since the menu
  just selects between different canonical forms; but a given canonical
  form may still mean multiple locations.

* I have thought about resurrecting my I/T set code from
  archer-tromey-multi-inferior.  Now that linespec iterates over
  program spaces this would actually be pretty useful, I think.
  I suspect it would be better to do this as a follow-up patch.

* Once it is all working I plan to rebase the SystemTap patches on top
  of this branch.

Tom

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Archer] update on ambiguous linespec branch
  2011-08-25 20:53 update on ambiguous linespec branch Tom Tromey
@ 2011-08-26  1:41 ` Joel Brobecker
  2011-08-26  2:08   ` Tom Tromey
  2011-08-26  1:45 ` Tom Tromey
  1 sibling, 1 reply; 4+ messages in thread
From: Joel Brobecker @ 2011-08-26  1:41 UTC (permalink / raw)
  To: Tom Tromey; +Cc: Project Archer

> * I didn't yet implement the new linespec types, namely allowing
>   "OBJFILE:" as a prefix, or "FILE:FUNCTION:LINE" or
>   "FILE:FUNCTION:LABEL".
[...]
>   I don't think this item is really needed for the patch to go in.  It
>   could be done as a follow-up, and IMO would be better that way, since
>   it will be a second huge change to linespec.c.

On the practical side, I'm wondering how you are going to be able
to implement the case where the user selects a sub-set of all matches
without this part... For instance, if there are two functions called
foobar, and the user types "break foobar", if he selects only to
break on one of them (using the multiple choice menu), how are we
going to support that without the linespec types above?

Or are you thinking of adding support for that as a second step?

-- 
Joel

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: update on ambiguous linespec branch
  2011-08-25 20:53 update on ambiguous linespec branch Tom Tromey
  2011-08-26  1:41 ` [Archer] " Joel Brobecker
@ 2011-08-26  1:45 ` Tom Tromey
  1 sibling, 0 replies; 4+ messages in thread
From: Tom Tromey @ 2011-08-26  1:45 UTC (permalink / raw)
  To: Project Archer

Tom> Here's my remaining to-do list.  I will work on it before my break, but
Tom> probably won't finish it.

I forgot to mention that I haven't run make check -- I've just been
madly hacking away, making a few selected tests work.  So, I'm sure
there are tons of regressions right now.

Tom

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Archer] update on ambiguous linespec branch
  2011-08-26  1:41 ` [Archer] " Joel Brobecker
@ 2011-08-26  2:08   ` Tom Tromey
  0 siblings, 0 replies; 4+ messages in thread
From: Tom Tromey @ 2011-08-26  2:08 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: Project Archer

Tom> * I didn't yet implement the new linespec types, namely allowing
Tom> "OBJFILE:" as a prefix, or "FILE:FUNCTION:LINE" or
Tom> "FILE:FUNCTION:LABEL".
[...]
Tom> I don't think this item is really needed for the patch to go in.  It
Tom> could be done as a follow-up, and IMO would be better that way, since
Tom> it will be a second huge change to linespec.c.

Joel> On the practical side, I'm wondering how you are going to be able
Joel> to implement the case where the user selects a sub-set of all matches
Joel> without this part... For instance, if there are two functions called
Joel> foobar, and the user types "break foobar", if he selects only to
Joel> break on one of them (using the multiple choice menu), how are we
Joel> going to support that without the linespec types above?

Joel> Or are you thinking of adding support for that as a second step?

Right now it works by filtering.

A linespec might resolve to multiple locations.  Each location has an
associated canonical form.  The canonical form has overload information
and the full symbol name, so e.g., "func" might be
"/blah/blah/file.c:func" or "/blah/blah/file.m:+[SomeClass func]".

Exactly how these are treated depends on the mode.  In
multiple-symbols=all, we just make a single breakpoint that matches
everything.  In multiple-symbols=ask, the menu sorts them by canonical
name; this could still result in multiple locations per breakpoint, for
example an inlined function has the same canonical form for all
locations.

When re-setting a breakpoint, the form the user entered ("func") is used
to search the symbol tables, but the chosen canonical form (for
multiple-symbols=all, NULL; but for multiple-symbols=ask, the particular
choice) is used to filter the resulting SALs.

Right now the canonical form is not displayed by "info break".  This is
a flaw.  Also, the canonical form cannot always be entered to the
"break" command.  These are both things that a follow-up series could
fix.

Currently the canonical form only includes the source file name, if any.
So one cannot distinguish functions in different objfiles yet.  I'm
actually not sure if you really want this -- an inline function may be
inlined in multiple objfiles.  Also the canonical form for a minimal
symbol is just the symbol name (but these are filtered intelligently so
you can only have plain "func" mean more than one location you have
multiple instances, none of which have debuginfo).

Maybe I will just do it all and try to rebase it into submission before
submitting.  After reading the above it seems like perhaps the best
course.

I've appended the docs for decode_line_full from the branch.  It may
help explain how the general replacement for decode_line_1 works.  The
key missing pieces is that CANONICAL->SALS is a vector of (extended)
symtabs_and_lines structures.  "break" makes the same number of
breakpoints as there are elements in this vector.

Tom

/* Parse *ARGPTR as a linespec and return results.  This is the "full"
   interface to this module, which handles multiple results
   properly.

   FUNFIRSTLINE is nonzero if we want the resulting SALs to describe
   the first line of indicated functions.

   DEFAULT_SYMTAB and DEFAULT_LINE describe the default location.
   DEFAULT_SYMTAB can be NULL, in which case the current symtab and
   line are used.

   CANONICAL is where the results are stored.  It must not be NULL.

   SELECT_MODE must be one of the multiple_symbols_* constants, or
   NULL.  It determines how multiple results will be handled.  If
   NULL, the appropriate CLI value will be used.

   FILTER can either be NULL or a string holding a canonical name.
   This is only valid when SELECT_MODE is multiple_symbols_all.

   Multiple results are handled differently depending on the
   arguments:

   . With multiple_symbols_cancel, an exception is thrown.

   . With multiple_symbols_ask, a menu is presented to the user.  The
   user may select none, in which case an exception is thrown; or all,
   which is handled like multiple_symbols_all, below.  Otherwise,
   CANONICAL->SALS will have one entry for each name the user chose.

   . With multiple_symbols_all, CANONICAL->SALS will have a single
   entry describing all the matching locations.  If FILTER is
   non-NULL, then only locations whose canonical name is equal (in the
   strcmp sense) to FILTER will be returned; all others will be
   filtered out.  */

extern void decode_line_full (char **argptr, int funfirstline,
			      struct symtab *default_symtab, int default_line,
			      struct linespec_result *canonical,
			      const char *select_mode,
			      const char *filter);

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-08-26  2:08 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-25 20:53 update on ambiguous linespec branch Tom Tromey
2011-08-26  1:41 ` [Archer] " Joel Brobecker
2011-08-26  2:08   ` Tom Tromey
2011-08-26  1:45 ` Tom Tromey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).