[Patch] Use "<unknown>" instead of NULL when a symbol isn't found

[Patch] Use "<unknown>" instead of NULL when a symbol isn't found

[Sterling Augustine]

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

When parsing a linespec without an enclosing symbol, add_sal_to_sals
(linespec.c:888) assigns "canonical->suffix = NULL;", but then, in
decode_line_full (linespec.c:2462) we have
"gdb_assert(state->canonical_names[i].suffix != NULL);"

Although the case is hard to tickle--I only found it myself with an
object file with an erroneous line table entry--GDB shouldn't crash,
and recovery is quite straight-forward.

The following patch simply assigns the symbol name as "<unknown>"
instead of NULL, allowing the debugger to make forward progress in the
face of an erroneous debug line table entry.

Sterling

gdb/ChangeLog
2013-12-17  Sterling Augustine  <saugustine@google.com>

        * linespec.c (add_sal_to_sals): Use "<unknown>" when a symbol
        isn't found.

[-- Attachment #2: canonical.patch --]
[-- Type: text/x-patch, Size: 384 bytes --]

diff --git a/gdb/linespec.c b/gdb/linespec.c
index 9468f26..e8bc695 100644
--- a/gdb/linespec.c
+++ b/gdb/linespec.c
@@ -885,7 +885,7 @@ add_sal_to_sals (struct linespec_state *self,
 	  if (symname != NULL)
 	    canonical->suffix = xstrdup (symname);
 	  else
-	    canonical->suffix = NULL;
+	    canonical->suffix = xstrdup ("<unknown>");
 	  canonical->symtab = NULL;
 	}
     }

Re: [Patch] Use "<unknown>" instead of NULL when a symbol isn't found

[Sterling Augustine]

On Tue, Dec 17, 2013 at 11:21 AM, Sterling Augustine
<saugustine@google.com> wrote:
> The following patch simply assigns the symbol name as "<unknown>"
> instead of NULL, allowing the debugger to make forward progress in the
> face of an erroneous debug line table entry.

Ping?

Re: [Patch] Use "<unknown>" instead of NULL when a symbol isn't found

[Tom Tromey]

>>>>> "Sterling" == Sterling Augustine <saugustine@google.com> writes:

Sterling> Although the case is hard to tickle--I only found it myself with an
Sterling> object file with an erroneous line table entry--GDB shouldn't crash,
Sterling> and recovery is quite straight-forward.

I wonder whether some correction or workaround is required elsewhere.

Sterling> The following patch simply assigns the symbol name as "<unknown>"
Sterling> instead of NULL, allowing the debugger to make forward progress in the
Sterling> face of an erroneous debug line table entry.

You didn't say whether you regression-tested this; but assuming so, it
is ok.

Tom

Re: [Patch] Use "<unknown>" instead of NULL when a symbol isn't found

[Sterling Augustine]

On Fri, Dec 20, 2013 at 10:16 AM, Tom Tromey <tromey@redhat.com> wrote:
> I wonder whether some correction or workaround is required elsewhere.

There are various parts of linepec.c that assume that this field is
never null, either by assertion or by dereferencing it. Any other
workaround (at least for the case I'm dealing with) would probably
just print an error message.

>
> Sterling> The following patch simply assigns the symbol name as "<unknown>"
> Sterling> instead of NULL, allowing the debugger to make forward progress in the
> Sterling> face of an erroneous debug line table entry.
>
> You didn't say whether you regression-tested this; but assuming so, it
> is ok.

I did run regressions and it didn't introduce any new ones.

Thanks. Committed as posted.

Re: [Patch] Use "<unknown>" instead of NULL when a symbol isn't found

[Tom Tromey]

>>>>> "Sterling" == Sterling Augustine <saugustine@google.com> writes:

Tom> I wonder whether some correction or workaround is required elsewhere.

Sterling> There are various parts of linepec.c that assume that this field is
Sterling> never null, either by assertion or by dereferencing it. Any other
Sterling> workaround (at least for the case I'm dealing with) would probably
Sterling> just print an error message.

Yeah, I meant more whether the symbol-reading code should try to
diagnose and avoid broken debuginfo here.

Tom