[patch] pr1430

[patch] pr1430

[Matt Rice]

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

here is an attempt at fixing pr1430

canonicalizes to file.m:foo or file.m:-[AClass foo]
which is how it knows that foo is a function and it shouldn't attempt
to look up a method
named foo. not sure if this should be done in decode_line_2 based on
language setting?

so if you move files around or anything you have to reset your
breakpoints, but i would take that over an endless loop.

matt

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

Index: linespec.c
===================================================================
RCS file: /cvs/src/src/gdb/linespec.c,v
retrieving revision 1.74
diff -u -p -r1.74 linespec.c
--- linespec.c	1 Jan 2008 22:53:11 -0000	1.74
+++ linespec.c	14 Mar 2008 19:55:20 -0000
@@ -1155,7 +1155,19 @@ decode_objc (char **argptr, int funfirst
   if (i1 > 1)
     {
       /* More than one match. The user must choose one or more.  */
-      return decode_line_2 (sym_arr, i2, funfirstline, canonical);
+      values = decode_line_2 (sym_arr, i2, funfirstline, canonical);
+      for (i2 = 0; i2 < values.nelts; i2++)
+	{
+	  char **canonical_arr = *canonical;
+	  char *canonical_name = canonical_arr[i2];
+	  char *filename = values.sals[i2].symtab->filename;
+	  char *file_canonical = xmalloc(strlen(filename) + strlen(canonical_name)
+						 + sizeof(":\0"));
+
+	  sprintf(file_canonical, "%s:%s", filename, canonical_name); 
+	  canonical_arr[i2] = file_canonical;
+	  xfree(canonical_name);
+	}
     }
 
   return values;

Re: [patch] pr1430

[Daniel Jacobowitz]

On Fri, Mar 14, 2008 at 01:38:12PM -0700, Matt Rice wrote:
> here is an attempt at fixing pr1430
> 
> canonicalizes to file.m:foo or file.m:-[AClass foo]
> which is how it knows that foo is a function and it shouldn't attempt
> to look up a method
> named foo. not sure if this should be done in decode_line_2 based on
> language setting?
> 
> so if you move files around or anything you have to reset your
> breakpoints, but i would take that over an endless loop.

This isn't safe; there might not be a filename.  Aren't we getting
canonicalized to file.m:-[AClass foo] already?
build_canonical_line_spec should do it.

A harder version of this problem will come up if you have a
non-debuggable symbol named foo.  We won't have a filename to put
in front of it.  So how do we know it's already been canonicalized?
This is sort of like what the Apple patch did in the audit trail.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [patch] pr1430

[Matt Rice]

On Fri, Mar 21, 2008 at 7:16 AM, Daniel Jacobowitz <drow@false.org> wrote:
>
> On Fri, Mar 14, 2008 at 01:38:12PM -0700, Matt Rice wrote:
>  > here is an attempt at fixing pr1430
>  >
>  > canonicalizes to file.m:foo or file.m:-[AClass foo]
>  > which is how it knows that foo is a function and it shouldn't attempt
>  > to look up a method
>  > named foo. not sure if this should be done in decode_line_2 based on
>  > language setting?
>  >
>  > so if you move files around or anything you have to reset your
>  > breakpoints, but i would take that over an endless loop.
>
>  This isn't safe; there might not be a filename.  Aren't we getting
>  canonicalized to file.m:-[AClass foo] already?
>  build_canonical_line_spec should do it.

no, we're not getting a file.m:-[AClass foo] from  decode_line_2
where the canonical is being setup as only an -[AClass foo] not a
filespec

in decode_objc the function i'm patching, it only calls
build_canonical_line_spec if i1 == 1, and in this case i1 > 1

further build_canonical_line_spec is incapable of dealing with
symtabs_and_lines, it can be called with symtab_and_line * but it
can't be called multiple times to create canonical filespec from
symtabs_and_lines as it'll just set the first item in the canonical
each time called.

with the existing canonical it would also leak them, since its
expecting to be creating a new canonical, so we kinda want a new
function for this?

I don't know how to get no filename except the case described below...

>  A harder version of this problem will come up if you have a
>  non-debuggable symbol named foo.  We won't have a filename to put
>  in front of it.  So how do we know it's already been canonicalized?
>  This is sort of like what the Apple patch did in the audit trail.

I can't currently test this without first fixing pr1236 there is a
patch in 1261, decode_line_2 never shows any non-debuggable objc
methods in the picker list,

and therefore it isn't possible for there to be any non-debuggable
symbols and i'm always hesitant to guess...

so I suppose i need to attack this first... i will try what mentioned
in your subsequent email after i get that working.

matt

Re: [patch] pr1430

[Daniel Jacobowitz]

On Fri, Mar 14, 2008 at 01:38:12PM -0700, Matt Rice wrote:
> here is an attempt at fixing pr1430
> 
> canonicalizes to file.m:foo or file.m:-[AClass foo]
> which is how it knows that foo is a function and it shouldn't attempt
> to look up a method
> named foo. not sure if this should be done in decode_line_2 based on
> language setting?

It occurs to me that this is just like the situation in Chris's patch
that was sent right after this one... we could canonicalize a
nondebuggable foo to 'foo' with quotes, maybe?  Or does that search
ObjC selectors too?


-- 
Daniel Jacobowitz
CodeSourcery