[RFC] canonical linespec and multiple breakpoints ...

[RFC] canonical linespec and multiple breakpoints ...

[Joel Brobecker]

Hello,

Re: [PATCH 2/6] Introduce `pre_expanded sals'
    http://www.sourceware.org/ml/gdb-patches/2011-04/msg00038.html
    http://www.sourceware.org/ml/gdb-patches/2011-05/msg00074.html

Jerome and I were discussing a way to move foward without having
to design everything, as the week is rapidly getting to a close.
(Jerome heads back to Paris at the end of this week, and will
be back to his normal schedule, so we're trying to take advantage
of his presence his as much as we can).

If we agree that a breakpoint expression (linespec) that gets resolved
into multiple source locations (slocs) should result in one breakpoint
per sloc, then we can start working on that.

The above requires that we agree on a way to make sure that each
breakpoint carries enough information to re-set itself, which means
that the information should make the breakpoint unique. We've handled
that issue by using a canonical linespec (FILE:FUNCTION:LINE), and
it has worked well for us.

I think that implementing the above in a way that allows each language
to implement their own way of dealing with templates/generics/homonyms
should be reasonably easy, and we'd still be much farther ahead than
we are now. What Jerome and I propose is that we implement the
infrastructure to make it work for C, and possibly Ada (we'll probably
wait for the Ada bits until the infrastructure is approved). We would
rather let the C++ bits to someone else, as we still have limited
experience with C++ itself.

We think that this will handle most situations, except the situation
where new symbols cause extra slocs to appear (typically, a shared
library gets mapped in memory). We are planing on plugging that hole
as a followup, which can be made independently, for instance using
Pedro's idea of introducing an extra level of breakpoint. The exact
details on how this is going to be done need to be discussed, but,
in the meantime, our experience with Ada show that the approach
we are proposing as a first step has been working well for our users.

Thoughts?

Thanks,
-- 
Joel

Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> If we agree that a breakpoint expression (linespec) that gets resolved
Joel> into multiple source locations (slocs) should result in one breakpoint
Joel> per sloc, then we can start working on that.

I am not sure about this plan.  I think it relies on being able to
differentiate breakpoints based on canonical linespecs, but I don't
think it is always possible to construct these.

E.g., consider the case where a linespec resolves to two locations, one
of which does not have debuginfo.  What is the canonical linespec for
the debuginfo-less location?  What if there are three locations and two
of them don't have debuginfo?  I.e., are those two consolidated into a
single breakpoint?  What would its canonical linespec be?  Or if not
consolidated, etc.

Joel> We would rather let the C++ bits to someone else, as we still have
Joel> limited experience with C++ itself.

Sounds good to me.

Joel> We think that this will handle most situations, except the situation
Joel> where new symbols cause extra slocs to appear (typically, a shared
Joel> library gets mapped in memory). We are planing on plugging that hole
Joel> as a followup, which can be made independently, for instance using
Joel> Pedro's idea of introducing an extra level of breakpoint. The exact
Joel> details on how this is going to be done need to be discussed, but,
Joel> in the meantime, our experience with Ada show that the approach
Joel> we are proposing as a first step has been working well for our users.

I would rather start with a comprehensive plan.  My concern about
approaching this piecemeal is that I think dealing with changes in the
inferior will necessitate changes in the basic approach.

Also, I think to get the SystemTap patch set in, I have to solve the
bigger problem anyhow.  That is, I have to start there, at least as I
understand the current situation.


I keep coming back to the "simple" approach I sketched here:

    http://sourceware.org/ml/gdb-patches/2011-04/msg00567.html

I can try to write this up into a fuller proposal if you want.

While looking into this area I made a list of difficulties and
considerations that I know of.  I can write that up in a readable form
if you think that would help.

Tom

Re: [RFC] canonical linespec and multiple breakpoints ...

[Joel Brobecker]

Hey Tom,

thanks for the feedback.

> I am not sure about this plan.  I think it relies on being able to
> differentiate breakpoints based on canonical linespecs, but I don't
> think it is always possible to construct these.

Indeed, I think it is true that there are going to be times when no
canonical linespec is ever going to be unique enough.  For instance,
the rather non-sensical case where two homonym routines are implemented
on the same line of code.  However:

> E.g., consider the case where a linespec resolves to two locations, one
> of which does not have debuginfo.  What is the canonical linespec for
> the debuginfo-less location?  What if there are three locations and two
> of them don't have debuginfo?  I.e., are those two consolidated into a
> single breakpoint?  What would its canonical linespec be?  Or if not
> consolidated, etc.

I think that, in a case where we have matches in code with debug
info, we shouldn't even bother looking at code without debugging
info. I think that this would be reasonable. There should be other
ways for the user to break on those instances that don't have
debug info he that's really what he meant.

> I keep coming back to the "simple" approach I sketched here:
> 
>     http://sourceware.org/ml/gdb-patches/2011-04/msg00567.html
> 
> I can try to write this up into a fuller proposal if you want.

Which part of your message would be the approach that you are
referring to?  There are two proposals that I can see:
  - the 3rd-tier breakpoint
  - one multi-location breakpoint (meaning that we break on all
    matches regardless)

The second approach is going to be really be tough to me to sell
to the Ada users. This is why I emphasized this aspect in my other
email (it was lengthy, I apologize). I have some ideas on maybe
finding a way to make it match our goals, but I'd rather make sure
I know exactly what you meant.

-- 
Joel

Re: [RFC] canonical linespec and multiple breakpoints ...

[Jan Kratochvil]

On Fri, 06 May 2011 00:40:16 +0200, Joel Brobecker wrote:
> I think that, in a case where we have matches in code with debug
> info, we shouldn't even bother looking at code without debugging
> info. I think that this would be reasonable. There should be other
> ways for the user to break on those instances that don't have
> debug info he that's really what he meant.

You have commonly system libraries debug info installed and you debug some
unpackaged application without debug info.  You see there application function
`next_line', you `break next_line' on it.

Oops, the breakpoint is missed, it broke on libc static function `next_line'
and not on the application function.


Thanks,
Jan

Re: [RFC] canonical linespec and multiple breakpoints ...

[Joel Brobecker]

> You have commonly system libraries debug info installed and you debug
> some unpackaged application without debug info.  You see there
> application function `next_line', you `break next_line' on it.
> 
> Oops, the breakpoint is missed, it broke on libc static function
> `next_line' and not on the application function.

OK. This means that we need to have a canonical form for symbols
without debug info as well. We actually have something for Ada
that could be extended to all languages, I think: We use angle
brackets to denote the fact that an entity name is a linkage
name.  For instance:

        break <my_function_linkage_name>

-- 
Joel

Re: [RFC] canonical linespec and multiple breakpoints ...

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: gdb-patches@sourceware.org
> Date: Thu, 05 May 2011 14:49:14 -0600
> 
>     http://sourceware.org/ml/gdb-patches/2011-04/msg00567.html
> 
> I can try to write this up into a fuller proposal if you want.
> 
> While looking into this area I made a list of difficulties and
> considerations that I know of.  I can write that up in a readable form
> if you think that would help.

Please do, and thanks.

Re: [RFC] canonical linespec and multiple breakpoints ...

[Eli Zaretskii]

> Date: Thu, 5 May 2011 15:40:16 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> > E.g., consider the case where a linespec resolves to two locations, one
> > of which does not have debuginfo.  What is the canonical linespec for
> > the debuginfo-less location?  What if there are three locations and two
> > of them don't have debuginfo?  I.e., are those two consolidated into a
> > single breakpoint?  What would its canonical linespec be?  Or if not
> > consolidated, etc.
> 
> I think that, in a case where we have matches in code with debug
> info, we shouldn't even bother looking at code without debugging
> info. I think that this would be reasonable.

Not reasonable enough, IMO: we are silently ignoring some of the
places where the user probably wanted to break.  Displaying some
warning about those places without debug info would be good enough,
though.

Re: [RFC] canonical linespec and multiple breakpoints ...

[Matt Rice]

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

On Thu, May 5, 2011 at 9:42 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> You have commonly system libraries debug info installed and you debug
>> some unpackaged application without debug info.  You see there
>> application function `next_line', you `break next_line' on it.
>>
>> Oops, the breakpoint is missed, it broke on libc static function
>> `next_line' and not on the application function.
>
> OK. This means that we need to have a canonical form for symbols
> without debug info as well. We actually have something for Ada
> that could be extended to all languages, I think: We use angle
> brackets to denote the fact that an entity name is a linkage
> name.  For instance:
>
>        break <my_function_linkage_name>

here's a hastily thrown together hack of the approach I was
considering when i was looking at objective-c's ambiguity problems...

basically adding a decoder_info thing (which doesn't really contain
anything useful atm)

the idea is that we return this in linespec_result, and pass it back
in on the next call to decode_line_1

in the case of objc it being non-null should be enough to
disambiguate, if its non-null we're looking for an 'exact match' of
the name, otherwise we can return ambiguous results.

it may also be nice if we want to jump directly to the specific
decoder, instead of running them all sequentially every time on
re_set...

its an update of an older patch hasn't been tested very well/looked at
in a long time but seems to pass the testsuite with only racy
differences

[-- Attachment #2: foo.diff --]
[-- Type: application/octet-stream, Size: 14123 bytes --]

diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index b5fc448..d5eb537 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -64,6 +64,7 @@
 #include "xml-syscall.h"
 #include "parser-defs.h"
 #include "cli/cli-utils.h"
+#include "linespec.h"
 
 /* readline include files */
 #include "readline/readline.h"
@@ -7337,7 +7338,8 @@ create_breakpoint_sal (struct gdbarch *gdbarch,
 		       enum bptype type, enum bpdisp disposition,
 		       int thread, int task, int ignore_count,
 		       struct breakpoint_ops *ops, int from_tty,
-		       int enabled, int internal, int display_canonical)
+		       int enabled, int internal, int display_canonical,
+		       struct linespec_breakpoint_info *decoder_info)
 {
   struct breakpoint *b = NULL;
   int i;
@@ -7446,6 +7448,7 @@ create_breakpoint_sal (struct gdbarch *gdbarch,
 	}
     }   
 
+  b->decoder_info = decoder_info;
   b->display_canonical = display_canonical;
   if (addr_string)
     b->addr_string = addr_string;
@@ -7631,7 +7634,10 @@ create_breakpoints_sal (struct gdbarch *gdbarch,
 			     cond_string, type, disposition,
 			     thread, task, ignore_count, ops,
 			     from_tty, enabled, internal,
-			     canonical->special_display);
+			     canonical->special_display,
+			     canonical->decoder_info
+			     ? canonical->decoder_info[i]
+			     : NULL);
     }
 }
 
@@ -7698,10 +7704,10 @@ parse_breakpoint_sals (char **address,
  	      || ((strchr ("+-", (*address)[0]) != NULL)
  		  && ((*address)[1] != '['))))
 	*sals = decode_line_1 (address, 1, default_breakpoint_symtab,
-			       default_breakpoint_line, canonical);
+			       default_breakpoint_line, canonical, NULL);
       else
 	*sals = decode_line_1 (address, 1, (struct symtab *) NULL, 0,
-		               canonical);
+		               canonical, NULL);
     }
   /* For any SAL that didn't have a canonical string, fill one in.  */
   if (sals->nelts > 0 && canonical->canonical == NULL)
@@ -7925,8 +7931,12 @@ create_breakpoint (struct gdbarch *gdbarch,
 
       copy_arg = savestring (addr_start, arg - addr_start);
       canonical.canonical = xcalloc (sals.nelts, sizeof (char *));
+      canonical.decoder_info = xcalloc (sals.nelts, sizeof (struct linespec_breakpoint_info **));
       for (i = 0; i < sals.nelts; i++)
-	canonical.canonical[i] = xstrdup (copy_arg);
+	{
+	  canonical.canonical[i] = xstrdup (copy_arg);
+	  canonical.decoder_info[i] = NULL;
+	}
       goto done;
     }
 
@@ -8072,7 +8082,8 @@ create_breakpoint (struct gdbarch *gdbarch,
 				     tempflag ? disp_del : disp_donttouch,
 				     thread, task, ignore_count, ops,
 				     from_tty, enabled, internal,
-				     canonical.special_display);
+				     canonical.special_display,
+				     canonical.decoder_info[i]);
 
 	      do_cleanups (old_chain);
 
@@ -8117,6 +8128,7 @@ create_breakpoint (struct gdbarch *gdbarch,
       b->enable_state = enabled ? bp_enabled : bp_disabled;
       b->pspace = current_program_space;
       b->py_bp_object = NULL;
+      b->decoder_info = NULL;
 
       if (enabled && b->pspace->executing_startup
 	  && (b->type == bp_breakpoint
@@ -8576,7 +8588,7 @@ break_range_command (char *arg, int from_tty)
      range.  This makes it possible to have ranges like "foo.c:27, +14",
      where +14 means 14 lines from the start location.  */
   sals_end = decode_line_1 (&arg, 1, sal_start.symtab, sal_start.line,
-			    &canonical_end);
+			    &canonical_end, NULL);
 
   /* canonical_end can be NULL if it was of the form "*0xdeadbeef".  */
   if (canonical_end.canonical == NULL)
@@ -9259,9 +9271,9 @@ until_break_command (char *arg, int from_tty, int anywhere)
 
   if (default_breakpoint_valid)
     sals = decode_line_1 (&arg, 1, default_breakpoint_symtab,
-			  default_breakpoint_line, NULL);
+			  default_breakpoint_line, NULL, NULL);
   else
-    sals = decode_line_1 (&arg, 1, (struct symtab *) NULL, 0, NULL);
+    sals = decode_line_1 (&arg, 1, (struct symtab *) NULL, 0, NULL, NULL);
 
   if (sals.nelts != 1)
     error (_("Couldn't get information on specified line."));
@@ -10946,7 +10958,7 @@ addr_string_to_sals (struct breakpoint *b, char *addr_string, int *found)
 	    error (_("marker %s not found"), b->static_trace_marker_id);
 	}
       else
-	sals = decode_line_1 (&s, 1, (struct symtab *) NULL, 0, NULL);
+	sals = decode_line_1 (&s, 1, (struct symtab *) NULL, 0, NULL, b->decoder_info);
     }
   if (e.reason < 0)
     {
@@ -11613,10 +11625,10 @@ decode_line_spec_1 (char *string, int funfirstline)
     sals = decode_line_1 (&string, funfirstline,
 			  default_breakpoint_symtab,
 			  default_breakpoint_line,
-			  NULL);
+			  NULL, NULL);
   else
     sals = decode_line_1 (&string, funfirstline,
-			  (struct symtab *) NULL, 0, NULL);
+			  (struct symtab *) NULL, 0, NULL, NULL);
   if (*string)
     error (_("Junk at end of line specification: %s"), string);
   return sals;
diff --git a/gdb/breakpoint.h b/gdb/breakpoint.h
index 7a9c2d4..f3ccfcd 100644
--- a/gdb/breakpoint.h
+++ b/gdb/breakpoint.h
@@ -651,6 +651,9 @@ struct breakpoint
 
     /* Whether this watchpoint is exact (see target_exact_watchpoints).  */
     int exact;
+
+    /* We hold onto this for, and pass it back in to decode_line_1.  */
+    struct linespec_breakpoint_info *decoder_info;
   };
 
 typedef struct breakpoint *breakpoint_p;
diff --git a/gdb/cli/cli-cmds.c b/gdb/cli/cli-cmds.c
index 7fd2f50..0fc5efc 100644
--- a/gdb/cli/cli-cmds.c
+++ b/gdb/cli/cli-cmds.c
@@ -787,7 +787,7 @@ edit_command (char *arg, int from_tty)
       /* Now should only be one argument -- decode it in SAL.  */
 
       arg1 = arg;
-      sals = decode_line_1 (&arg1, 0, 0, 0, 0);
+      sals = decode_line_1 (&arg1, 0, 0, 0, 0, 0);
 
       if (! sals.nelts)
 	{
@@ -917,7 +917,7 @@ list_command (char *arg, int from_tty)
     dummy_beg = 1;
   else
     {
-      sals = decode_line_1 (&arg1, 0, 0, 0, 0);
+      sals = decode_line_1 (&arg1, 0, 0, 0, 0, 0);
 
       if (!sals.nelts)
 	return;			/*  C++  */
@@ -950,9 +950,9 @@ list_command (char *arg, int from_tty)
       else
 	{
 	  if (dummy_beg)
-	    sals_end = decode_line_1 (&arg1, 0, 0, 0, 0);
+	    sals_end = decode_line_1 (&arg1, 0, 0, 0, 0, 0);
 	  else
-	    sals_end = decode_line_1 (&arg1, 0, sal.symtab, sal.line, 0);
+	    sals_end = decode_line_1 (&arg1, 0, sal.symtab, sal.line, 0, 0);
 	  if (sals_end.nelts == 0)
 	    return;
 	  if (sals_end.nelts > 1)
diff --git a/gdb/linespec.c b/gdb/linespec.c
index 94bb86f..4bd459c 100644
--- a/gdb/linespec.c
+++ b/gdb/linespec.c
@@ -146,6 +146,8 @@ static struct
 symtabs_and_lines minsym_found (int funfirstline,
 				struct minimal_symbol *msymbol);
 
+struct linespec_breakpoint_info *make_decoder_info(enum linespec_decoder_func_id);
+
 /* Helper functions.  */
 
 /* Issue a helpful hint on using the command completion feature on
@@ -788,7 +790,8 @@ keep_name_info (char *ptr)
 
 struct symtabs_and_lines
 decode_line_1 (char **argptr, int funfirstline, struct symtab *default_symtab,
-	       int default_line, struct linespec_result *canonical)
+	       int default_line, struct linespec_result *canonical,
+	       struct linespec_breakpoint_info *decoder_info)
 {
   char *p;
   char *q;
@@ -822,7 +825,17 @@ decode_line_1 (char **argptr, int funfirstline, struct symtab *default_symtab,
   /* See if arg is *PC.  */
 
   if (**argptr == '*')
-    return decode_indirect (argptr);
+    {
+      if (canonical)
+        {
+	  struct linespec_breakpoint_info **decoder_info;
+
+	  decoder_info = xmalloc (sizeof (struct linespec **) * 1);
+	  decoder_info[0] = make_decoder_info (decoder_indirect);
+	  canonical->decoder_info = decoder_info;
+        }
+      return decode_indirect (argptr);
+    }
 
   is_quoted = (strchr (get_gdb_completer_quote_characters (),
 		       **argptr) != NULL);
@@ -853,6 +866,21 @@ decode_line_1 (char **argptr, int funfirstline, struct symtab *default_symtab,
 
     values = decode_objc (argptr, funfirstline, NULL,
 			  canonical, saved_arg);
+    if (canonical && values.sals)
+      {
+	struct linespec_breakpoint_info **decoder_info;
+	int i;
+
+	decoder_info = xmalloc (sizeof (struct linespec **) * values.nelts);
+
+	for (i = 0; i < values.nelts; i++)
+          {
+	    decoder_info[i] = make_decoder_info (decoder_objc);
+	  }
+
+	canonical->decoder_info = decoder_info;
+      }
+
     if (values.sals != NULL)
       return values;
   }
@@ -878,6 +906,22 @@ decode_line_1 (char **argptr, int funfirstline, struct symtab *default_symtab,
 				    saved_arg, p);
 	  if (is_quoted && **argptr == '\'')
 	    *argptr = *argptr + 1;
+
+	  if (canonical)
+            {
+	      struct linespec_breakpoint_info **decoder_info;
+	      int i;
+
+	      decoder_info = xmalloc (sizeof (struct linespec **)
+				      * values.nelts);
+
+	      for (i = 0; i < values.nelts; i++)
+		{
+		  decoder_info[i] = make_decoder_info (decoder_compound);
+		}
+
+	      canonical->decoder_info = decoder_info;
+            }
 	  return values;
 	}
 
@@ -1941,6 +1985,16 @@ decode_all_digits (char **argptr, struct symtab *default_symtab,
   if (need_canonical)
     build_canonical_line_spec (values.sals, NULL, canonical);
   values.sals[0].explicit_line = 1;
+
+  if (canonical)
+    {
+      struct linespec_breakpoint_info **decoder_info;
+
+      decoder_info = xmalloc (sizeof (struct linespec **) * 1);
+      decoder_info[0] = make_decoder_info (decoder_all_digits);
+      canonical->decoder_info = decoder_info;
+    }
+
   return values;
 }
 
@@ -1961,6 +2015,15 @@ decode_dollar (char *copy, int funfirstline, struct symtab *default_symtab,
   struct symbol *sym;
   struct minimal_symbol *msymbol;
 
+  if (canonical)
+    {
+      struct linespec_breakpoint_info **decoder_info;
+
+      decoder_info = xmalloc (sizeof (struct linespec **) * 1);
+      decoder_info[0] = make_decoder_info (decoder_dollar);
+      canonical->decoder_info = decoder_info;
+    }
+
   p = (copy[1] == '$') ? copy + 2 : copy + 1;
   while (*p >= '0' && *p <= '9')
     p++;
@@ -2039,6 +2102,15 @@ decode_label (struct symbol *function_symbol, char *copy,
   struct symbol *sym;
   struct block *block;
 
+  if (canonical)
+    {
+      struct linespec_breakpoint_info **decoder_info;
+
+      decoder_info = xmalloc (sizeof (struct linespec **) * 1);
+      decoder_info[0] = make_decoder_info (decoder_label);
+      canonical->decoder_info = decoder_info;
+    }
+
   if (function_symbol)
     block = SYMBOL_BLOCK_VALUE (function_symbol);
   else
@@ -2072,6 +2144,15 @@ decode_variable (char *copy, int funfirstline,
   struct symbol *sym;
   struct minimal_symbol *msymbol;
 
+  if (canonical)
+    {
+      struct linespec_breakpoint_info **decoder_info;
+
+      decoder_info = xmalloc (sizeof (struct linespec **) * 1);
+      decoder_info[0] = make_decoder_info (decoder_variable);
+      canonical->decoder_info = decoder_info;
+    }
+
   sym = lookup_symbol (copy,
 		       (file_symtab
 			? BLOCKVECTOR_BLOCK (BLOCKVECTOR (file_symtab),
@@ -2223,3 +2304,13 @@ init_linespec_result (struct linespec_result *lr)
 {
   memset (lr, 0, sizeof (*lr));
 }
+
+struct linespec_breakpoint_info *
+make_decoder_info(enum linespec_decoder_func_id decoder)
+{
+  struct linespec_breakpoint_info *decoder_info = xmalloc(sizeof(struct linespec_breakpoint_info));
+
+  decoder_info->decoder = decoder;
+
+  return decoder_info;
+}
diff --git a/gdb/linespec.h b/gdb/linespec.h
index 3c86af3..9324f85 100644
--- a/gdb/linespec.h
+++ b/gdb/linespec.h
@@ -20,6 +20,24 @@
 
 struct symtab;
 
+enum linespec_decoder_func_id {
+  decoder_unknown = 0,
+  decoder_compound,
+  decoder_objc,
+  decoder_label,
+  decoder_indirect,
+  decoder_all_digits,
+  decoder_dollar,
+  decoder_variable
+};
+
+/* If linespec returns one of these in linespec_result it wants you
+   to pass it back to it should you call decode_line_1 again.  */
+struct linespec_breakpoint_info
+{
+  enum linespec_decoder_func_id decoder;
+};
+
 /* An instance of this may be filled in by decode_line_1.  The caller
    must call init_linespec_result to initialize it.  */
 
@@ -37,6 +55,10 @@ struct linespec_result
      element in it are allocated with xmalloc and must be freed by the
      caller.  */
   char **canonical;
+
+  /* Stuff linespec wants breakpoint to hold onto and pass back on
+     breakpoint re setting. Same rules as canonical.  */
+  struct linespec_breakpoint_info **decoder_info;
 };
 
 /* Initialize a linespec_result.  */
@@ -46,6 +68,7 @@ extern void init_linespec_result (struct linespec_result *);
 extern struct symtabs_and_lines
 	decode_line_1 (char **argptr, int funfirstline,
 		       struct symtab *default_symtab, int default_line,
-		       struct linespec_result *canonical);
+		       struct linespec_result *canonical,
+		       struct linespec_breakpoint_info *decoder_info);
 
 #endif /* defined (LINESPEC_H) */
diff --git a/gdb/python/python.c b/gdb/python/python.c
index 8a7bc66..90d5dc8 100644
--- a/gdb/python/python.c
+++ b/gdb/python/python.c
@@ -454,7 +454,7 @@ gdbpy_decode_line (PyObject *self, PyObject *args)
 	  arg = xstrdup (arg);
 	  make_cleanup (xfree, arg);
 	  copy = arg;
-	  sals = decode_line_1 (&copy, 0, 0, 0, 0);
+	  sals = decode_line_1 (&copy, 0, 0, 0, 0, 0);
 	  make_cleanup (xfree, sals.sals);
 	}
       else
diff --git a/gdb/symtab.c b/gdb/symtab.c
index d98ac57..3645093 100644
--- a/gdb/symtab.c
+++ b/gdb/symtab.c
@@ -4395,7 +4395,7 @@ decode_line_spec (char *string, int funfirstline)
 
   sals = decode_line_1 (&string, funfirstline,
 			cursal.symtab, cursal.line,
-			NULL);
+			NULL, NULL);
 
   if (*string)
     error (_("Junk at end of line specification: %s"), string);
diff --git a/gdb/tracepoint.c b/gdb/tracepoint.c
index 119ab22..0226613 100644
--- a/gdb/tracepoint.c
+++ b/gdb/tracepoint.c
@@ -2333,7 +2333,7 @@ scope_info (char *args, int from_tty)
     error (_("requires an argument (function, "
 	     "line or *addr) to define a scope"));
 
-  sals = decode_line_1 (&args, 1, NULL, 0, NULL);
+  sals = decode_line_1 (&args, 1, NULL, 0, NULL, NULL);
   if (sals.nelts == 0)
     return;		/* Presumably decode_line_1 has already warned.  */
 

Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey]

Tom> I am not sure about this plan.  I think it relies on being able to
Tom> differentiate breakpoints based on canonical linespecs, but I don't
Tom> think it is always possible to construct these.

Joel> Indeed, I think it is true that there are going to be times when no
Joel> canonical linespec is ever going to be unique enough.  For instance,
Joel> the rather non-sensical case where two homonym routines are implemented
Joel> on the same line of code.

One thing I realized last night is that it is not necessary to require a
breakpoint's canonical location to be a linespec.  It could be some
other data structure with a more sophisticated equality algorithm.

This idea makes it possible to support a canonical descriptor of
"function named foo with no debuginfo" without requiring some convoluted
linespec representing this.

Even with this there are going to be bad cases.  E.g., the case in RH
bugzilla (I think a private bug -- sorry) concerns a program that
somehow embeds two different versions of the same library.  In a case
like this, many entities have the same names, file names, and line
numbers.

Tom> I keep coming back to the "simple" approach I sketched here:
Tom> http://sourceware.org/ml/gdb-patches/2011-04/msg00567.html
Tom> I can try to write this up into a fuller proposal if you want.

Joel> Which part of your message would be the approach that you are
Joel> referring to?  There are two proposals that I can see:
Joel>   - the 3rd-tier breakpoint
Joel>   - one multi-location breakpoint (meaning that we break on all
Joel>     matches regardless)

The latter.

Joel> The second approach is going to be really be tough to me to sell
Joel> to the Ada users. This is why I emphasized this aspect in my other
Joel> email (it was lengthy, I apologize). I have some ideas on maybe
Joel> finding a way to make it match our goals, but I'd rather make sure
Joel> I know exactly what you meant.

I will read your other note again, and Jerome's, and reply soon.

Tom

Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey]

Tom> While looking into this area I made a list of difficulties and
Tom> considerations that I know of.  I can write that up in a readable form
Tom> if you think that would help.

Eli> Please do, and thanks.

Here are the issues I know of.  I am not convinced that there is any
good way to get all the desirable features into a single model, but I
welcome brainstorming to this end.

I'm sorry this is so disorganized.  It resisted attempts by me to make
it more orderly.  I can try to flesh out any pieces that don't make
sense, or come up with difficult scenarios when something isn't clear.


First, there really is a problem.  I think it is worth pointing this
out.  Currently, given an ambiguous linespec, GDB picks a winner.  This
winner is unpredictable.

Right now only a `file:line' breakpoint can have multiple locations.
This is convenient for MI, though the problems here are fixable.  I
think this does also give a somewhat nice story for users when the
inferior changes; often (but not always) locations can be preserved, and
`file:line', especially once canonicalized, is reasonably unambiguous,
even across objfiles.  Tracking locations like this is desirable because
it means particular instances can be enabled or disabled and the user
can have some reasonable expectation that gdb will do the right thing
across re-runs, etc.  Note that the existing code here can be confounded
in some situations: macrology for sure, maybe different template
instantiations (but I didn't try this one particularly).

Breakpoint conditions interact with multi-location breakpoints.  A
condition needs a scope in which to parse.  A breakpoint that can truly
be multi-location could acquire a new location that invalidates previous
parses.

In the particular case of SystemTap probe points, I think it would be ok
to require multi-location breakpoint conditions to just use the global
scope plus any arguments passed to the probe.

Commands also interact with multi-location breakpoints, but less
significantly than conditions.  With a 3-tiered approach I wonder
whether it makes sense to attach commands at both outer tiers?  Or just
the outermost?

Canonicalization is an important problem to solve.  It matters at least
for the menu-choosing case, should we keep that.  I think Matt Rice hit
on the right idea here: instead of always canonicalizing to a linespec,
have some internal object that holds more state.  We probably also need
some new kind of linespec in order to let the user more precisely filter
locations.

It is worth thinking about what "the same" means when it comes to two
linespecs (or canonicalized objects).  E.g., consider "break function".
Is "function" the same across objfiles?  If so or not so, what is the
rationale?  For example, "function" might be an inline function defined
in a header, and so really should be treated the same across objfiles;
or maybe this case requires further filtering based on file:line.  Maybe
different sorts of linespecs require different comparators.

One consideration is what "the same" means when one location has
debuginfo and another does not.  Per an earlier email, I think this
negatively affects the 3-tier approach.

It is worth thinking about "time invariance".  E.g., suppose we adopt
Jerome's "menu" plan.  In this case, an ambiguous linespec can present
the user with a menu (depending on a setting).  But what happens if a
linespec is not ambiguous, but then becomes ambiguous due to changes in
the inferior?

Time invariance and canonicalization also affects the multi-inferior
case.  The current plan is to handle multi-inferior breakpoints using
I/T sets; but it seems to me that these may match names in different
ways across inferiors.  A simple example is just `break [*] main' --
this either makes a single breakpoint (with all the attendant true
multi-location problems), or binds eagerly (contra the `[*]' spec), or
introduces a tiered breakpoint (but with a more complex example perhaps
one requires 4 tiers?  It is unclear to me).

FWIW, on `archer-tromey-multi-breakpoint-2' I implemented a simple form
of multi-tiered breakpoints for the multi-inferior case.  On this branch
there is a new "multi break" command that makes a new kind of
breakpoint; this breakpoint is re-evalled for each matching inferior as
it is created, and may then create a new real breakpoint.  You can try
it out if you are curious; I think it worked ok, but not truly great
(better would have been making it a real kind of breakpoint so it could
have commands and whatnot).

Many commands, not just "break", use linespecs.  What I found was: list,
edit, func, tfind, and clear.  Also linespec is called by
select_source_symtab, but I think only for "main" (so could be done
differently).  Any solution has to deal with these commands in some way.

Linespecs are exposed to Python, so some updates are required there.  I
don't think this is too big a problem.  It is probably worth writing a
Python API to whatever canonicalized form exists.

Tom

Re: [RFC] canonical linespec and multiple breakpoints ...

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: brobecker@adacore.com, gdb-patches@sourceware.org
> Date: Thu, 26 May 2011 15:05:35 -0600
> 
> Tom> While looking into this area I made a list of difficulties and
> Tom> considerations that I know of.  I can write that up in a readable form
> Tom> if you think that would help.
> 
> Eli> Please do, and thanks.
> 
> Here are the issues I know of.  I am not convinced that there is any
> good way to get all the desirable features into a single model, but I
> welcome brainstorming to this end.

Thanks.  If others have more issues and considerations to share,
please do.

I think the next step is indeed to come up with a model for handling
these issues.  If we cannot come up with a single model for
everything, we could try 2 models (a-la your "multi break" command).

Maybe a useful interim step would be reworking the description you
posted into a concise list of broad use case classes and issues that
need to be solved in each class.  We can then brainstorm possible
solutions against that list.

Re: [RFC] canonical linespec and multiple breakpoints ...

[Matt Rice]

On Thu, May 26, 2011 at 2:05 PM, Tom Tromey <tromey@redhat.com> wrote:

> Right now only a `file:line' breakpoint can have multiple locations.

possibly semantics, but I also noticed that this works with
`file:label', in the case of assembly with debuginfo
when running add-symbol-file, and debugging across kernel relocation
process using qemu.

e.g.
3       breakpoint     keep y   0x80200044 ../../kernel/lostart.S:156
(gdb) c
....
3.1                         y     0x80200044 ../../kernel/lostart.S:156
3.2                         y     0x80000044 ../../kernel/lostart.S:156
....
(gdb) c

3.1                         y     0x80200044 ../../kernel/lostart.S:156
3.2                         y     0x80000044 ../../kernel/lostart.S:156
3.3                         y     0xfe000044 ../../kernel/lostart.S:156

Re: [RFC] canonical linespec and multiple breakpoints ...

[Matt Rice]

On Thu, May 26, 2011 at 2:05 PM, Tom Tromey <tromey@redhat.com> wrote:

> It is worth thinking about "time invariance".  E.g., suppose we adopt
> Jerome's "menu" plan.  In this case, an ambiguous linespec can present
> the user with a menu (depending on a setting).  But what happens if a
> linespec is not ambiguous, but then becomes ambiguous due to changes in
> the inferior?
>
> Time invariance and canonicalization also affects the multi-inferior
> case.  The current plan is to handle multi-inferior breakpoints using
> I/T sets; but it seems to me that these may match names in different
> ways across inferiors.  A simple example is just `break [*] main' --
> this either makes a single breakpoint (with all the attendant true
> multi-location problems), or binds eagerly (contra the `[*]' spec), or
> introduces a tiered breakpoint (but with a more complex example perhaps
> one requires 4 tiers?  It is unclear to me).

I guess it is worth noting that I had previously thought about the
Time invariance problem in isolation of the grouping problem.

At that time what I had imagined was a 'perpetually pending
breakpoint', or a 'pending rolling snowball breakpoint', basically a
pending breakpoint which is not removed when it is resolved, it
inserts the resolved breakpoint, but does not remove the pending one.

thinking about the grouping mechanism also in isolation leads one to
consider the idea of 'breakpoint groups',
where the 'perpetually pending breakpoint', contains a group ID, and
when it resolves, the newly inserted breakpoint gets inserted into the
same group as its pending one.

If a breakpoint group could contain breakpoint groups, as well as
breakpoints, we have a tiering mechanism.

Additionally i could see some benefit in being able to enable/disable
whole groups of breakpoints at a time.

Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey]

Eli> Maybe a useful interim step would be reworking the description you
Eli> posted into a concise list of broad use case classes and issues that
Eli> need to be solved in each class.  We can then brainstorm possible
Eli> solutions against that list.

Here are the various scenarios in a more CLI-centric way.  I think it is
important to consider how a proposed plan handles each one.  Note that
in many cases the content of the linespec is unimportant, nearly any of
them can be made to be ambiguous; this happens in real programs.

1. Break on an ambiguously-named function.

    $ gdb gdb
    (gdb) break parse_number

  Today we pick one:

    Breakpoint 1 at 0x7e7a54: file ../../src/gdb/p-exp.y, line 856.


2. The same, but with a file:line.


3. Set a breakpoint at a SystemTap probe, the thing that started all this:

    (gdb) break probe:longjmp

   This one (in Fedora 15 glibc) happens to have 2 locations.


4. Set a pending breakpoint.

   (gdb) break lib_function

5. The same, but the pending name is ambiguous.

6. Set a breakpoint that has a match in the inferior.  Then the inferior
   loads a .so to make the linespec ambiguous.

7. 'break main', then start multiple inferiors

8. Any of the above, but with a breakpoint condition.
   Of particular importance is the case where the condition cannot be
   parsed in one location.

9. An ambiguous linespec where one match has debuginfo and another does
   not.


I left off the MI and Python stuff.  I don't think those will have a
significant impact on the choices; the question is really how we want
the user to interact with GDB.

I will post my proposal and rundown of the scenarios separately.

Tom

Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey]

Here is my proposal for how to handle ambiguous linespecs.  First I'll
describe it in general terms, with a few specifics about the
implementation.  Then I'll describe how it handles each scenario I
posted yesterday.

I would appreciate comments on this.  This is what I intend to work on
starting next Monday, and I would not like to be in the position where I
put in a lot of work and then have to redo it all.

I welcome contrasting proposals, but particularly if they address all
the scenarios identified thus far.  I think that partial solutions are
much less interesting -- it is easy to do well on any particular facet
of the problem, but it is much tougher, I think, to come up with a
complete solution.


I propose a simple rule for the handling of ambiguous linespecs: a
breakpoint whose argument is ambiguous will fire at all matching
locations.  This rule has several properties that I consider desirable:

* It is simple to explain to users
* It is predictable
* It is time-invariant
* It is implementable ;-)

In addition to this rule I think we should introduce some new linespec
syntax, to let users more precisely narrow down breakpoints.  In
particular I would like to add objfile names as a prefix, like:

  (gdb) break libc.so:malloc

I think I/T sets are also a good idea here, for the multi-inferior case.
These have been discussed several times and I think don't need much more
discussion.

In order to properly re-set breakpoints, we need a canonical form of the
linespec.  Currently this is done by constructing a new canonicalized
linespec.  In my proposal we will replace this with a structure, the
better to add more precise behavior without needing to construct
linespec syntax for every possible case.  E.g., we can have a bit
indicating whether this canonical linespec matches symbols without
debuginfo.

I am not sure how the breakpoint location information should be arranged
internally.  Perhaps each bp_location will need a canonical linespec
struct.

We'll continue to respect 'set multiple-symbols ask' -- in fact, we will
effectively expand it use by noticing more ambiguity in the first place.
This setting will provide users a way to easily create multiple
breakpoints from a single linespec (the "all" choice).

Linespecs are used in places other than "break", like "advance".  My
full list plus how to handle ambiguity:

* list, edit: give a menu.
* func: rewrite; I'm not sure why this even uses linespec
* until, advance: use the current context to filter the results; error
  if it is still ambiguous
* clear: work like breakpoints
* select_source_symtab: rewrite

One might note that this approach has a built-in inefficiency: nearly
every inferior change will require reading (this at a time when we are
trying to move more toward lazy reading) and scanning of debuginfo.  I
think this is ok provided that we provide users with better ways to
precisely specify linespecs; and also perhaps by modifying the internal
code to be smarter about computing re-sets depending on different kinds
of events -- like just dropping some locations rather than fully
re-evaluating a breakpoint when an objfile goes away.

The last part of the proposal is providing a way to modify a
breakpoint's linespec after the breakpoint has been made.  The rationale
for this is that it gives users a way to recover from ambiguity when a
condition is attached.  See below.


Now on to the scenarios:

Tom> 1. Break on an ambiguously-named function.
Tom>     $ gdb gdb
Tom>     (gdb) break parse_number

Make a single breakpoint with 7 locations -- one for each function in
gdb with this name.

Tom> 2. The same, but with a file:line.

Make a single breakpoint with multiple locations, just as today.

Tom> 3. Set a breakpoint at a SystemTap probe, the thing that started all this:
Tom>     (gdb) break probe:longjmp
Tom>    This one (in Fedora 15 glibc) happens to have 2 locations.

Likewise.

Tom> 4. Set a pending breakpoint.
Tom>    (gdb) break lib_function
Tom> 5. The same, but the pending name is ambiguous.

These both make a pending breakpoint; inferior changes may cause
locations to be added or removed.

If the name has no matches when 'break' is invoked, then we would
continue to respect 'set breakpoint pending'.

Tom> 6. Set a breakpoint that has a match in the inferior.  Then the inferior
Tom>    loads a .so to make the linespec ambiguous.

Add new locations to the breakpoint.

Tom> 7. 'break main', then start multiple inferiors

Each new inferior causes new locations to be added; gdb stops at the
'main' of each one.

Tom> 8. Any of the above, but with a breakpoint condition.
Tom>    Of particular importance is the case where the condition cannot be
Tom>    parsed in one location.

This, I think, is the one bad part of this proposal.  When a location is
added to a breakpoint, it may cause the condition to no longer be
parseable.

In this situation I think we should change gdb in 2 ways, to give the
user more control:

1. When a condition is no longer parseable, provide the option to stop
   the inferior so the user can correct it.
2. Also provide a way for the user to respecify the breakpoint location.

For the latter I think something like:

  modify breakpoint N location LINESPEC

Tom> 9. An ambiguous linespec where one match has debuginfo and another does
Tom>    not.

Handled by the canonical linespec struct.

Tom

Re: [RFC] canonical linespec and multiple breakpoints ...

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: brobecker@adacore.com, gdb-patches@sourceware.org
> Date: Thu, 30 Jun 2011 15:00:02 -0600
> 
> Eli> Maybe a useful interim step would be reworking the description you
> Eli> posted into a concise list of broad use case classes and issues that
> Eli> need to be solved in each class.  We can then brainstorm possible
> Eli> solutions against that list.
> 
> Here are the various scenarios in a more CLI-centric way.

Thanks.

> 2. The same, but with a file:line.

You mean, there's more than 1 file with the same basename?  "The same"
is slightly ambiguous here.

Re: [RFC] canonical linespec and multiple breakpoints ...

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Date: Fri, 01 Jul 2011 10:39:00 -0600
> 
> Here is my proposal for how to handle ambiguous linespecs.

Thanks.

> I think I/T sets are also a good idea here

What is an "I/T set"?

> Tom> 6. Set a breakpoint that has a match in the inferior.  Then the inferior
> Tom>    loads a .so to make the linespec ambiguous.
> 
> Add new locations to the breakpoint.

How about alerting the user to this effect, giving them an opportunity
to narrow the scope of the breakpoint?  We could have this as an
optional behavior, but IMO if the breakpoint was unambiguous when I
set it, I would like such an alert by default, because it could be
that I knew what I was doing, and GDB might be defeating me now.

OTOH, if the new-and-improved linespec will allow me to be specific
about this use case (i.e. I don't want any other locations be added),
perhaps this is not an issue.  On the third hand, I could be
forgetting something when I specify the breakpoint, and still be
surprised.

>   modify breakpoint N location LINESPEC

I think this kind of command is necessary not only for the use case
which led you to conclude that it's needed.  We need this to let the
user re-specify location based on dynamically changing environment of
the debugging session: shared libraries being loaded and unloaded,
inferiors starting and exiting, etc.

(As for the command name, I'd suggest "location N LINESPEC", btw.)

I would also recommend an option to stop and suggest such changes
whenever any event happens that would normally trigger addition of
another location, but _before_ such a location is added -- e.g.,
because putting a breakpoint on some locations has undesirable side
effect, like in embedded systems.

IOW, we should give the user more control on the precise linespec,
including when the original linespec turns out to be different from
what it was when typed.

You say nothing about watchpoints.  Will they also use the same
infrastructure?

> I welcome contrasting proposals

Sorry, I don't have any ;-)

Thanks again for working on this.

Re: [RFC] canonical linespec and multiple breakpoints ...

[Joel Brobecker]

> Here is my proposal for how to handle ambiguous linespecs.  First I'll
> describe it in general terms, with a few specifics about the
> implementation.  Then I'll describe how it handles each scenario I
> posted yesterday.

Overal, I think that this is a very nice proposal.

> I propose a simple rule for the handling of ambiguous linespecs: a
> breakpoint whose argument is ambiguous will fire at all matching
> locations.

I think that this is a good general rule, and something we should
encourage our users to use. But it seems that it does not cover
the case where 'set multiple-symbols ask' is in use, does it?
My understanding, when `ask' is that, if the user selects `all',
then we're in the case above (fire at all locations, add new locations
as we discover them), but if the user selects a sub-sets of the
potential matches, what should we do?

My suggestion, in that case, is to make the list of selected
locations static.  In other words, we do not add new locations
as they get discovered.

The typical scenario is when we have multiple instantiations of
a given generic, and the user is only interested in debugging
one, or at least a small subset.  In that case, a typical user
debugging using a GUI or an IDE will click on the code, which
is often translated into a FILE:LINE linespec.

> In order to properly re-set breakpoints, we need a canonical form of the
> linespec.  Currently this is done by constructing a new canonicalized
> linespec.  In my proposal we will replace this with a structure, the
> better to add more precise behavior without needing to construct
> linespec syntax for every possible case.  E.g., we can have a bit
> indicating whether this canonical linespec matches symbols without
> debuginfo.

I think it's important to have some kind of canonical form that
the user's can use as the linespec as well. That way, they can
enter a linespec that, in the vast majority of cases, is not
ambiguous.  For our purposes, FILE:FUNCTION:LINE has worked really
well...

> I am not sure how the breakpoint location information should be arranged
> internally.  Perhaps each bp_location will need a canonical linespec
> struct.

I would think so.

> Tom> 4. Set a pending breakpoint.
> Tom>    (gdb) break lib_function
> Tom> 5. The same, but the pending name is ambiguous.
> 
> These both make a pending breakpoint; inferior changes may cause
> locations to be added or removed.

So, pending breakpoints are implicitly treated as breakpoints
with multiple-symbols set to `all', right? I think that'd be fair.

> Tom> 7. 'break main', then start multiple inferiors
> 
> Each new inferior causes new locations to be added; gdb stops at the
> 'main' of each one.

I hadn't thought about that. I thought that breakpoints were specific
to a given inferior, but I guess we'd want that, at least in certain
scenarios (the ones where we're trying to follow a process and all
its children for instance). I think this behavior makes sense, new
inferior and new SOs can be treated the same.

> Tom> 8. Any of the above, but with a breakpoint condition.
> Tom>    Of particular importance is the case where the condition cannot be
> Tom>    parsed in one location.
> 
> This, I think, is the one bad part of this proposal.  When a location is
> added to a breakpoint, it may cause the condition to no longer be
> parseable.
> 
> In this situation I think we should change gdb in 2 ways, to give the
> user more control:
> 
> 1. When a condition is no longer parseable, provide the option to stop
>    the inferior so the user can correct it.
> 2. Also provide a way for the user to respecify the breakpoint location.
> 
> For the latter I think something like:
> 
>   modify breakpoint N location LINESPEC

Looks good.  By extension, we could also allow 'modify breakpoint N
condition', as an alias of the 'cond' command (I am not suggesting
this too seriously, just to say that I like the `modify <object>'
syntax, which we can extend for other stuff we might need in the
future).

-- 
Joel

Re: [RFC] canonical linespec and multiple breakpoints ...

[Jerome Guitton]

Joel Brobecker (brobecker@adacore.com):

> I think that this is a good general rule, and something we should
> encourage our users to use. But it seems that it does not cover
> the case where 'set multiple-symbols ask' is in use, does it?
> My understanding, when `ask' is that, if the user selects `all',
> then we're in the case above (fire at all locations, add new locations
> as we discover them), but if the user selects a sub-sets of the
> potential matches, what should we do?
> 
> My suggestion, in that case, is to make the list of selected
> locations static.  In other words, we do not add new locations
> as they get discovered.

I would suggest a slightly different rule: all breakpoints are still
"multiple" by default. No "static" one. But, in the case of 'set
multiple-symbols ask' and when one symbol is selected, then a
breakpoint will be set, whose location will not be ambiguous (it will
be "canonicalized"). So this "multiple" breakpoint will always
resolve to only one location. If more than one choice is selected,
same thing, with one breakpoint per choice.

I'd rather avoid adding a special breakpoint kind for 'ask'. Just to
keep it simple.

Re: [RFC] canonical linespec and multiple breakpoints ...

[Joel Brobecker]

> > My suggestion, in that case, is to make the list of selected
> > locations static.  In other words, we do not add new locations
> > as they get discovered.
> 
> I would suggest a slightly different rule: all breakpoints are still
> "multiple" by default. No "static" one. But, in the case of 'set
> multiple-symbols ask' and when one symbol is selected, then a
> breakpoint will be set, whose location will not be ambiguous (it will
> be "canonicalized"). So this "multiple" breakpoint will always
> resolve to only one location. If more than one choice is selected,
> same thing, with one breakpoint per choice.
> 
> I'd rather avoid adding a special breakpoint kind for 'ask'. Just to
> keep it simple.

That would be fine with me.  But, in a way, you're also deviating
from the general case by going from a one-bp-multiple-loc approach
to a multiple-bp-single-loc approach. Either way, I think it can
raise questions from the user...

-- 
Joel

Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Tom> I think I/T sets are also a good idea here

Eli> What is an "I/T set"?

http://sourceware.org/ml/gdb/2008-08/msg00169.html

>> modify breakpoint N location LINESPEC

Eli> (As for the command name, I'd suggest "location N LINESPEC", btw.)

I wanted a way to also change the 'silent' flag.

It occurred to me last night that we could use "set" instead of
"modify":

    set breakpoint N location LINESPEC
    set breakpoint N silent [on|off]

Eli> You say nothing about watchpoints.  Will they also use the same
Eli> infrastructure?

I don't think it is necessary.  "watch" doesn't take a linespec
argument.

Tom

Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey]

Joel> I think that this is a good general rule, and something we should
Joel> encourage our users to use. But it seems that it does not cover
Joel> the case where 'set multiple-symbols ask' is in use, does it?
Joel> My understanding, when `ask' is that, if the user selects `all',
Joel> then we're in the case above (fire at all locations, add new locations
Joel> as we discover them), but if the user selects a sub-sets of the
Joel> potential matches, what should we do?

Joel> My suggestion, in that case, is to make the list of selected
Joel> locations static.  In other words, we do not add new locations
Joel> as they get discovered.

This was part of the proposal but I think it should have been more
prominent.

My proposal was that in 'ask' mode, 'break' makes a separate
canonicalized breakpoint for each location the user requests.

I had proposed making the 'all' choice make N different breakpoints,
each "static".  But now I think that 'all' should mean "make a dynamic
breakpoint covering all locations", and the user can create separate
static breakpoints by entering "2-57" (e.g.) at the prompt.  This gives
the user a way to achieve multiple-symbols=all behavior without having
to temporarily change the setting.

I think we must specify what "static" means -- by specifying the
canonicalization algorithm.  When I consider the difference between your
proposal and Jerome's, I think the distinction largely relies on what
exactly it means to canonicalize a location.

FWIW I would be satisfied with any of several possible solutions
(including yours and Jerome's) to the multiple-symbols=ask scenario.

Joel> The typical scenario is when we have multiple instantiations of
Joel> a given generic, and the user is only interested in debugging
Joel> one, or at least a small subset.  In that case, a typical user
Joel> debugging using a GUI or an IDE will click on the code, which
Joel> is often translated into a FILE:LINE linespec.

Do IDEs actually run in multiple-symbols = ask mode?
My understanding was that these interactive prompts caused headaches for
MI users.

Tom> In order to properly re-set breakpoints, we need a canonical form of the
Tom> linespec.  Currently this is done by constructing a new canonicalized
Tom> linespec.  In my proposal we will replace this with a structure, the
Tom> better to add more precise behavior without needing to construct
Tom> linespec syntax for every possible case.  E.g., we can have a bit
Tom> indicating whether this canonical linespec matches symbols without
Tom> debuginfo.

Joel> I think it's important to have some kind of canonical form that
Joel> the user's can use as the linespec as well. That way, they can
Joel> enter a linespec that, in the vast majority of cases, is not
Joel> ambiguous.  For our purposes, FILE:FUNCTION:LINE has worked really
Joel> well...

When I wrote this I was specifically thinking of the situation where a
breakpoint has some matches with debuginfo and some without.  I didn't
see much value in having a linespec covering the "functions named X
without debuginfo" case.

FILE:FUNCTION:LINE makes sense to me, I think it would be useful for C++
templates as well.

Tom> 4. Set a pending breakpoint.
Tom> (gdb) break lib_function
Tom> 5. The same, but the pending name is ambiguous.
Tom> These both make a pending breakpoint; inferior changes may cause
Tom> locations to be added or removed.

Joel> So, pending breakpoints are implicitly treated as breakpoints
Joel> with multiple-symbols set to `all', right? I think that'd be fair.

Yes.

Tom

Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Tom> 2. The same, but with a file:line.

Eli> You mean, there's more than 1 file with the same basename?  "The same"
Eli> is slightly ambiguous here.

I mean, the same as scenario #1.
To rephrase:

2. Break on an ambiguously-named location using file:line.

   (gdb) break something.c:73

   where the program has more than one "something.c" compiled in.

Tom

Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey]

>>>>> "Matt" == Matt Rice <ratmice@gmail.com> writes:

Matt> If a breakpoint group could contain breakpoint groups, as well as
Matt> breakpoints, we have a tiering mechanism.

This was also Pedro's approach -- a third tier.

I prefer the proposal I posted on the basis of simplicity.
Also, it is tough to evaluate other ideas without a more complete
analysis of the various scenarios.

Matt> Additionally i could see some benefit in being able to enable/disable
Matt> whole groups of breakpoints at a time.

This is already possible with 'enable 1-23'.  I'm not sure if this is
possible with individual locations ('enable 1.5-1.7'), but I don't see
why it couldn't be done.

Tom

Re: [RFC] canonical linespec and multiple breakpoints ...

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: gdb-patches@sourceware.org
> Date: Tue, 05 Jul 2011 13:18:13 -0600
> 
> Eli> (As for the command name, I'd suggest "location N LINESPEC", btw.)
> 
> I wanted a way to also change the 'silent' flag.

And I wanted it to be consistent with how we modify breakpoints today,
once they are set ("conditions", "commands", "enable", etc.).

I'm okay with having one command for that, but then we should lump all
those into it, too, for consistency.

> It occurred to me last night that we could use "set" instead of
> "modify":
> 
>     set breakpoint N location LINESPEC
>     set breakpoint N silent [on|off]

Also possible (although currently we use that for minor options), but
again, we should then add command, conditions, etc. to that as well.

> Eli> You say nothing about watchpoints.  Will they also use the same
> Eli> infrastructure?
> 
> I don't think it is necessary.  "watch" doesn't take a linespec
> argument.

But they can be ambiguous as well.

Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

>> I don't think it is necessary.  "watch" doesn't take a linespec
>> argument.

Eli> But they can be ambiguous as well.

Ok, that is true, but I am not proposing also tackling expression
ambiguity at the same time.  I think it is too difficult.

Tom

Re: [RFC] canonical linespec and multiple breakpoints ...

[Matt Rice]

On Tue, Jul 5, 2011 at 12:59 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Matt" == Matt Rice <ratmice@gmail.com> writes:
>
> Matt> If a breakpoint group could contain breakpoint groups, as well as
> Matt> breakpoints, we have a tiering mechanism.
>
> This was also Pedro's approach -- a third tier.
>
> I prefer the proposal I posted on the basis of simplicity.
> Also, it is tough to evaluate other ideas without a more complete
> analysis of the various scenarios.
>

The attempt was to provide a simple fix for ambiguity, such as yours,

and then separately implement grouping as a distinct concept/mechanism.
I think it's more middle of the road between Pedro's and your proposal,

I don't see why we couldn't implement the grouping mechanism
separately on top of yours
should someone want to, personally for the purpose of the discussion at hand,
I believe your proposal is suffice.

Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey]

First of all, pinging Pedro -- I would greatly appreciate your
commentary to help unblock this project.

Tom> I propose a simple rule for the handling of ambiguous linespecs: a
Tom> breakpoint whose argument is ambiguous will fire at all matching
Tom> locations.  This rule has several properties that I consider desirable:

Tom> * It is simple to explain to users
Tom> * It is predictable
Tom> * It is time-invariant
Tom> * It is implementable ;-)

This week while discussing this and other things on irc, we came up with
a possible problem with the proposal: it interacts poorly with lazy
debuginfo reading.

Right now there are several patches (and planned patches) to make
debuginfo reading lazier: my lazy reading patch for new inferiors,
Sergio's work, and Gary and Paul both have work in this area too.  These
all rely on the idea that, generally, loading a new .so doesn't mean
that we must necessarily read its debuginfo.

However, with the plan as proposed, GDB will in most cases become much
less lazy-capable.  While the proposal addresses this in part by letting
users specify breakpoint locations more precisely, this will not happen
by default -- "break main" will still mean loading all the debuginfo for
everything gdb sees.

So, a slightly different approach to solving this would be to make
breakpoints capture their location set at the "point of resolution" --
either immediately, or for a pending breakpoint, the first time it hits.
Then, provide some additional syntax to make a "permanently pending"
breakpoint.

This approach would provide efficiency by default ("break main" would
typically resolve to a single location, not requiring any extra
debuginfo reads in the future) with an option for a more dynamic
approach for those circumstances requiring it.

I am not completely sold on this, but I wanted to float the idea for
comments.

I think this might imply some cleanup of the current breakpoint
re-setting approach.

Tom

Re: [RFC] canonical linespec and multiple breakpoints ...

[Matt Rice]

On Tue, Jul 26, 2011 at 12:53 PM, Tom Tromey <tromey@redhat.com> wrote:
>
> I am not completely sold on this, but I wanted to float the idea for
> comments.

I guess, a case where this one acts oddly is,

there is a currently unambiguously resolvable function,
which will become ambiguous on future shared library processing.

in that case you need a way to force a pending breakpoint.

also because outside of dlopen there is generally no prompt in between
shared library processing, usage of a 'permanent pending breakpoint'
will cause debug-info for all shared libraries to be processed in
between run and the gdb prompt.

it doesn't seem like it is incompatible with foo.so:function_of_doom
style breakpoints
that could be used to mitigate the chewing through all debug-info too.

it doesn't gracefully/effortlessly handle ambiguous breakpoints like
the previous solution, but to me that isn't that big of an issue, as
long as there is a way to handle them when they are encountered.
That there is some way to resolve an ambiguous location to the one I
want gdb to stop at, rather than that it manages to resolve all
ambiguous linespecs.

Shrug.

Re: [RFC] canonical linespec and multiple breakpoints ...

[Jan Kratochvil]

On Tue, 26 Jul 2011 21:53:15 +0200, Tom Tromey wrote:
> So, a slightly different approach to solving this would be to make
> breakpoints capture their location set at the "point of resolution" --
> either immediately, or for a pending breakpoint, the first time it hits.
> Then, provide some additional syntax to make a "permanently pending"
> breakpoint.

I find it OK.  With various lazy reads it may be more useful your unapplied
read-debuginfos-by-background-thread patch.  If it finds later an existing
breakpoint could have another location in the newly read debuginfo it could
warn the user s/he should use the "permanently pending" form next time.
But that feature may be too far from now.


Thanks,
Jan

Re: [RFC] canonical linespec and multiple breakpoints ...

[Matt Rice]

On Tue, Jul 26, 2011 at 12:53 PM, Tom Tromey <tromey@redhat.com> wrote:
> First of all, pinging Pedro -- I would greatly appreciate your
> commentary to help unblock this project.
>
> Tom> I propose a simple rule for the handling of ambiguous linespecs: a
> Tom> breakpoint whose argument is ambiguous will fire at all matching
> Tom> locations.  This rule has several properties that I consider desirable:
>
> Tom> * It is simple to explain to users
> Tom> * It is predictable
> Tom> * It is time-invariant
> Tom> * It is implementable ;-)
>
> This week while discussing this and other things on irc, we came up with
> a possible problem with the proposal: it interacts poorly with lazy
> debuginfo reading.
>

Another approach which would work with lazy debuginfo reading would be
to modify your original proposal with a continuation.  Change 'fire at
all matching locations'.  to 'find one or more matches stopping at the
first object file to provide a match'
then embedding a continuation into the breakpoint and a command to
'resume finding matches'.

It seems a more involved implementation than the 'permanent pending
breakpoint' option...

thus the interface would be something like:
break foo
resolve-next-match BPNUM
resolve-all-matches BPNUM

(or the appropriate `modify' variant)
and so on until finding the "foo" that is wanted, or object files are exhausted.

it doesn't hit: '* it is predictable' because its outcome is order
dependent, and the commands may need to be run number-of-matches
times.

i'm not really leaning in preference to either option, just wanted to
put the idea out there.

Re: [RFC] canonical linespec and multiple breakpoints ...

[Pedro Alves]

On Tuesday 26 July 2011 20:53:15, Tom Tromey wrote:
> First of all, pinging Pedro -- I would greatly appreciate your
> commentary to help unblock this project.

I'm very sorry for the delay in responding to this.  It turns
out the world didn't stop when I went on vacation, for some
unknown reason, and I've took a long time to catch up...  I
wanted to read the whole discussion and think at least a bit
before replying...

I'm sold on going your proposed direction, and forgetting the
3-level breakpoints approach.  

I believe it provides a similar experience to what TotalView
users are used to, FWIW.

> 
> Tom> I propose a simple rule for the handling of ambiguous linespecs: a
> Tom> breakpoint whose argument is ambiguous will fire at all matching
> Tom> locations.  This rule has several properties that I consider desirable:
> 
> Tom> * It is simple to explain to users
> Tom> * It is predictable
> Tom> * It is time-invariant

Okay, agreed.

> Tom> * It is implementable ;-)

:-)  I think breakpoint_ops'ing all things would make 3-tier
easier, but that's moot now.

> 
> This week while discussing this and other things on irc, we came up with
> a possible problem with the proposal: it interacts poorly with lazy
> debuginfo reading.

I don't think it's a good idea to confuse the user interface
design with some optimizations.  I'd rather we have "correct"
before "optimized".  "unsurprising" before "super fast".

> Right now there are several patches (and planned patches) to make
> debuginfo reading lazier: my lazy reading patch for new inferiors,

I never replied to your patch, but my reaction was that it is
probably breaking breakpoints in the new inferiors today,
even without any linespec/multi breakpoints work.  Wouldn't
e.g., making debug info reading smarter (the sharing of
objfiles between inferiors work/idea?) mostly dispense that
approach?

It's not just user breakpoints that worry me with simply avoiding
debug info altogether with some per-inferior flag, rather than
making it depeng on need/request.  E.g., activating thread
library debugging usually needs at least minimal symbols.
Another example, GDB currently only invites the remote end to ask if
it wants GDB to resolve some symbols (qSymbol) after loading the
objfile.  With a lazy scheme, we should let the remote end know (send
it a qSymbol) there's  potentially new symbols available, even if
we haven't yet read the debug info.  If the remote end replies
with a request, we can read the debug info then.

> Sergio's work, and Gary and Paul both have work in this area too.  These
> all rely on the idea that, generally, loading a new .so doesn't mean
> that we must necessarily read its debuginfo.
> 
> However, with the plan as proposed, GDB will in most cases become much
> less lazy-capable.  While the proposal addresses this in part by letting
> users specify breakpoint locations more precisely, this will not happen
> by default -- "break main" will still mean loading all the debuginfo for
> everything gdb sees.
> So, a slightly different approach to solving this would be to make
> breakpoints capture their location set at the "point of resolution" --
> either immediately, or for a pending breakpoint, the first time it hits.
> Then, provide some additional syntax to make a "permanently pending"
> breakpoint.
> 
> This approach would provide efficiency by default ("break main" would
> typically resolve to a single location, not requiring any extra
> debuginfo reads in the future) with an option for a more dynamic
> approach for those circumstances requiring it.
> 
> I am not completely sold on this, but I wanted to float the idea for
> comments.

I'm not sold on this either.  One could do something similar,
but leavy the default the way around -- have a new "final"
property/option of breakpoints --- once it's spec resolves,
it no longer gets locations auto-added, and have the user
request for final'ness explicitly.  The "final" property
does not need to be final itself, it could be toggleable.

What I don't think I have seen addressed is how the proposal
interacts with multi-exec.  E.g, suppose I have program foo
loaded once (one inferior) and program bar loaded twice (two
inferiors).  I have one of the bar inferiors in focus, 
and I do "b main".  How many locations does this resolve to?
One, two, or three?  Currently, it resolves to two.

> 
> I think this might imply some cleanup of the current breakpoint
> re-setting approach.

-- 
Pedro Alves

Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> I'm very sorry for the delay in responding to this.

It is no problem, and thanks for replying.

Tom> Right now there are several patches (and planned patches) to make
Tom> debuginfo reading lazier: my lazy reading patch for new inferiors,

Pedro> I never replied to your patch, but my reaction was that it is
Pedro> probably breaking breakpoints in the new inferiors today, even
Pedro> without any linespec/multi breakpoints work.

Is there a way to set a breakpoint in a new inferior without first
loading the debuginfo by hand?  It has been a while since I was looking
at this, but I don't remember finding a way.

If there is one, though, I can easily test this.

Pedro> Wouldn't e.g., making debug info reading smarter (the sharing of
Pedro> objfiles between inferiors work/idea?) mostly dispense that
Pedro> approach?

That would help for much of the debuginfo, but not all of it.  I think
it would depend on how much sharing there is across inferiors in a given
session.

FWIW I have taken a couple stabs at making objfile sharing work.  It is
a lot harder than I thought it would be, and it winds up requiring
conditions which I am not confident are always true.

The big problem comes from symbols.  In the new setup, symbols are
independent of the program space.  SYMBOL_VALUE_ADDRESS still needs the
program space, though -- so we add a mapping from objfile to the
per-program-space objfile wrapper.  But, to actually use this map, the
current program space must be set properly at any use of
SYMBOL_VALUE_ADDRESS.  It isn't clear to me that this is guaranteed.  I
think there are other cases like this too.

Pedro> It's not just user breakpoints that worry me with simply avoiding
Pedro> debug info altogether with some per-inferior flag, rather than
Pedro> making it depeng on need/request.
[...]

Thanks, this is very helpful info.

Pedro> I'm not sold on this either.  One could do something similar,
Pedro> but leavy the default the way around -- have a new "final"
Pedro> property/option of breakpoints --- once it's spec resolves,
Pedro> it no longer gets locations auto-added, and have the user
Pedro> request for final'ness explicitly.  The "final" property
Pedro> does not need to be final itself, it could be toggleable.

Ok.  I will implement it the "full" way first; if we find it isn't so
good in practice we can always change it or add an option later on.

Pedro> What I don't think I have seen addressed is how the proposal
Pedro> interacts with multi-exec.  E.g, suppose I have program foo
Pedro> loaded once (one inferior) and program bar loaded twice (two
Pedro> inferiors).  I have one of the bar inferiors in focus, 
Pedro> and I do "b main".  How many locations does this resolve to?
Pedro> One, two, or three?  Currently, it resolves to two.

Three, following the rule that a breakpoint will fire at all matching
locations.

Tom

Re: [RFC] canonical linespec and multiple breakpoints ...

[Pedro Alves]

On Tuesday 02 August 2011 18:08:46, Tom Tromey wrote:

> Pedro> I never replied to your patch, but my reaction was that it is
> Pedro> probably breaking breakpoints in the new inferiors today, even
> Pedro> without any linespec/multi breakpoints work.
> 
> Is there a way to set a breakpoint in a new inferior without first
> loading the debuginfo by hand?  It has been a while since I was looking
> at this, but I don't remember finding a way.
> 
> If there is one, though, I can easily test this.

If you set a breakpoint before the fork, the
breakpoint will end up with locations in the new inferior
after the fork.  Same if e.g., you set a breakpoint before
a fork/exec, and post-exec image happens to have
been compiled from the same code (file:lineno) as the 
original breakpoint's location was resolved to.  I was
under the impression your patch would make it so 
the new inferior would no longer stop for these breakpoints.

> Pedro> What I don't think I have seen addressed is how the proposal
> Pedro> interacts with multi-exec.  E.g, suppose I have program foo
> Pedro> loaded once (one inferior) and program bar loaded twice (two
> Pedro> inferiors).  I have one of the bar inferiors in focus, 
> Pedro> and I do "b main".  How many locations does this resolve to?
> Pedro> One, two, or three?  Currently, it resolves to two.
> 
> Three, following the rule that a breakpoint will fire at all matching
> locations.

Okay.

-- 
Pedro Alves

Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Finally replying to this old note.

The context for this note is this patch, which has not been checked in:

    http://sourceware.org/ml/gdb-patches/2011-03/msg00606.html

Pedro> I never replied to your patch, but my reaction was that it is
Pedro> probably breaking breakpoints in the new inferiors today, even
Pedro> without any linespec/multi breakpoints work.

Tom> Is there a way to set a breakpoint in a new inferior without first
Tom> loading the debuginfo by hand?  It has been a while since I was looking
Tom> at this, but I don't remember finding a way.

Tom> If there is one, though, I can easily test this.

Pedro> If you set a breakpoint before the fork, the
Pedro> breakpoint will end up with locations in the new inferior
Pedro> after the fork.  Same if e.g., you set a breakpoint before
Pedro> a fork/exec, and post-exec image happens to have
Pedro> been compiled from the same code (file:lineno) as the 
Pedro> original breakpoint's location was resolved to.  I was
Pedro> under the impression your patch would make it so 
Pedro> the new inferior would no longer stop for these breakpoints.

I finally tried this today by making a simple program that forks,
applying the patch to git master, enabling multi-inferior, and
debugging.  It works fine:

    (gdb) c
    Continuing.
    hi bob from 16888
    [New process 16889]

    Breakpoint 2, doit () at ft.c:6
    6	  printf ("hi bob from %d\n", (int) getpid());

I think this is what I would expect, anyway.  The patch in question
changes gdb to lazily read debuginfo for inferiors that arise from
forks.  But, in this scenario, breakpoint re-setting causes gdb to need
the debuginfo, so it is read at that point -- on demand.

I plan to check in this patch after 7.4 branches.

Tom

Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Tom> The context for this note is this patch, which has not been checked in:
Tom>     http://sourceware.org/ml/gdb-patches/2011-03/msg00606.html
[...]

Tom> I plan to check in this patch after 7.4 branches.

I'm finally checking it in now.

Tom

Re: [RFC] canonical linespec and multiple breakpoints ...

[Tom Tromey]

>>>>> "Avi" == Avi Gozlan <avi@checkpoint.com> writes:

Sorry about the delay in my reply.  I was offline all of September.

Avi> Among varying GDB uses, we use GDB to debug a process which loads
Avi> (using dlopen) the same exact library multiple times (in fact there
Avi> are copies of the library otherwise dlopen returns the same handle for
Avi> each load).

Avi> 1) The proposal discusses function breakpoints. Will it also enable
Avi> inspecting global and static variables from a specific library?

No, I'm afraid not.

I think implementing something for variables could be done, but it would
be a separate project, maybe with a different approach.  I can advise if
you are interested in this.

Avi> 2) Just to make sure we understand the interaction of the user
Avi> interface with "set multiple-symbols": it will be possible to request
Avi> GDB for a specific variable/function by a library name without getting
Avi> it from all libraries or get a question (ask) each time, right?
Avi> Otherwise it will be very inconvenient to inspect multiple variables
Avi> within a given library.

Yes, this will work as you expect.

Avi> 3) Will the library specific interface know how to handle non-stripped
Avi> libraries that are compiled without debug information (no "-g")?

Yes.  This is already implemented on my branch.  It improves GDB's
behavior here, so that the right thing happens if you have multiple
instance of a name where some symbols have debuginfo and some do not.

Avi> 4) We suggest adding an option to enable the GDB backtrace command to
Avi> show the library name for each function. In our usage case we have
Avi> scenarios in which the libraries interact with each other and a
Avi> backtrace showing the library name for each function can enable us
Avi> understand the interaction perfectly.

There was an earlier thread about this, I'm not sure what happened in
the end though.  I think this would be a good addition.  If there is no
bug report for this, could you file one?

Avi> 5) Perhaps a little pedantic but what about handling symbols with
Avi> different names in libraries with identical name which lie in
Avi> different paths?

I didn't implement the "objfile" prefix stuff yet, but my plan is to let
you specify as much of the path as you want, e.g.:

  break libsomething.so:function
  break /lib/libsomething.so:function
  break some/leading/dirs/libsomething.so:function

Tom

Re: [RFC] canonical linespec and multiple breakpoints ...

[Avi Gozlan]

Hello,

On the basis of your proposal dealing with supporting multiple breakpoints and the discussion that followed it, I would like to raise some questions. These issues are highly relevant for our needs (the need was first described in bug 12313 in the GDB bug database).

Among varying GDB uses, we use GDB to debug a process which loads (using dlopen) the same exact library multiple times (in fact there are copies of the library otherwise dlopen returns the same handle for each load). We find your proposal very useful for us to be able to attach to the process and debug a specific library. Though, we do have some questions and suggestions. Pardon technical inaccuracies in GDB terminology.
 
1) The proposal discusses function breakpoints. Will it also enable inspecting global and static variables from a specific library?

2) Just to make sure we understand the interaction of the user interface with "set multiple-symbols": it will be possible to request GDB for a specific variable/function by a library name without getting it from all libraries or get a question (ask) each time, right? Otherwise it will be very inconvenient to inspect multiple variables within a given library.

3) Will the library specific interface know how to handle non-stripped libraries that are compiled without debug information (no "-g")?

4) We suggest adding an option to enable the GDB backtrace command to show the library name for each function. In our usage case we have scenarios in which the libraries interact with each other and a backtrace showing the library name for each function can enable us understand the interaction perfectly.

5) Perhaps a little pedantic but what about handling symbols with different names in libraries with identical name which lie in different paths?

Thanks,

Avi