"Unrecognized demangle component" error

"Unrecognized demangle component" error

[Dave Korn]

  I've got this big executable (that uses the wxWindows library, a huge C++
cross-platform gui api), built with gcc version

(GCC) 3.3.3 (cygwin special)

and binutils version

GNU assembler 2.15.91 20040725

(they all report the same timestamp).  When I try debugging it with gdb, I
found that all the line number info was badly messed up.  So I thought I'd
take a look at the debugging info with objdump and see what I could see, and
what I saw was this:

--------------------<snip!>--------------------
dk@mace /test> objdump -g macsim.exe

macsim.exe:     file format pei-i386

Unrecognized demangle component
--------------------<snip!>--------------------

  Wow.  I've never before come across an error message that brings up so few
hits at google.  That's probably because ILT only added it in January:

http://sources.redhat.com/ml/binutils/2004-01/msg00192.html

and I see from the following FIXME that it's not a big surprise that it
sometimes fails:

+      /* FIXME: These are demangle component types which we probably
+	 need to handle one way or another.  */

  Anyway, I don't know a lot about the interactions round here, but I was
wondering if this problem could have had a knockon effect on gdb making it
lose track of the line tables.  I'm not too familiar with the internal gdb
commands for trying to debug these problems, so I was wondering if anyone
had a few suggestions to try?  Here's an example of how wrong it goes:

dk@mace /artimi/firmware/build/debug-i686-pc-cygwin/macsim> gdb ./macsim.exe
GNU gdb 2003-09-20-cvs (cygwin-special)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) list main
29      } tBerPoint;
30
31      // This class should be specialised for concrete phy layers
32      class CphyLayer
33      {
34      public:
35          CphyLayer(){}
36          virtual ~CphyLayer(){}
37
38          // Frame detection
(gdb)


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: "Unrecognized demangle component" error

[Ian Lance Taylor]

"Dave Korn" <dk@artimi.com> writes:

> --------------------<snip!>--------------------
> dk@mace /test> objdump -g macsim.exe
> 
> macsim.exe:     file format pei-i386
> 
> Unrecognized demangle component
> --------------------<snip!>--------------------
> 
>   Wow.  I've never before come across an error message that brings up so few
> hits at google.  That's probably because ILT only added it in January:
> 
> http://sources.redhat.com/ml/binutils/2004-01/msg00192.html
> 
> and I see from the following FIXME that it's not a big surprise that it
> sometimes fails:
> 
> +      /* FIXME: These are demangle component types which we probably
> +	 need to handle one way or another.  */

I wonder which component it was.  I should have had the error message
print it out the number.  It would probably also be friendlier to
print a warning and then return debug_make_void_type (dhandle).

>   Anyway, I don't know a lot about the interactions round here, but I was
> wondering if this problem could have had a knockon effect on gdb making it
> lose track of the line tables.

That is unlikely.  The demangled name is used to determine the
argument types and the return type of static methods.  It is not used
for anything involving line numbers.

I don't know what is causing the line number trouble.

Ian

RE: "Unrecognized demangle component" error

[Dave Korn]

> -----Original Message-----
> From: binutils-owner On Behalf Of Ian Lance Taylor
> Sent: 22 October 2004 20:53

> "Dave Korn" writes:
> 
> > --------------------<snip!>--------------------
> > dk@mace /test> objdump -g macsim.exe
> > 
> > macsim.exe:     file format pei-i386
> > 
> > Unrecognized demangle component
> > --------------------<snip!>--------------------
> > 
> >   Wow.  I've never before come across an error message that 
> brings up so few
> > hits at google.  That's probably because ILT only added it 
> in January:
> > 
> > http://sources.redhat.com/ml/binutils/2004-01/msg00192.html
> > 
> > and I see from the following FIXME that it's not a big 
> surprise that it
> > sometimes fails:
> > 
> > +      /* FIXME: These are demangle component types which 
> we probably
> > +	 need to handle one way or another.  */
> 
> I wonder which component it was.  I should have had the error message
> print it out the number.  It would probably also be friendlier to
> print a warning and then return debug_make_void_type (dhandle).

  OK, I quickly plumbed in those changes (using 2.15 release sources), and see
that they're all without exception references to type #34 which I make out to be
DEMANGLE_COMPONENT_FUNCTION_TYPE.  Ummm.  I would imagine that's a slightly
surprising result, perhaps?

> That is unlikely.  The demangled name is used to determine the
> argument types and the return type of static methods.  It is not used
> for anything involving line numbers.
> 
> I don't know what is causing the line number trouble.

  Thanks Ian, I'll look into that one a bit further.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: "Unrecognized demangle component" error

[Ian Lance Taylor]

"Dave Korn" <dk@artimi.com> writes:

> > I wonder which component it was.  I should have had the error message
> > print it out the number.  It would probably also be friendlier to
> > print a warning and then return debug_make_void_type (dhandle).
> 
>   OK, I quickly plumbed in those changes (using 2.15 release sources), and see
> that they're all without exception references to type #34 which I make out to be
> DEMANGLE_COMPONENT_FUNCTION_TYPE.  Ummm.  I would imagine that's a slightly
> surprising result, perhaps?

That's what I would expect from a static method which takes a function
pointer as a parameter.  For example, I can recreate the problem with
this one-liner:
    class C { static int foo(int (*pfn)(int)); };
So it's not especially unlikely, it's just not handled.

Since you bring it up, I just checked in this patch to handle it.

Ian

Index: stabs.c
===================================================================
RCS file: /cvs/src/src/binutils/stabs.c,v
retrieving revision 1.20
diff -u -p -r1.20 stabs.c
--- stabs.c	12 Jan 2004 21:08:00 -0000	1.20
+++ stabs.c	25 Oct 2004 15:24:44 -0000
@@ -203,6 +203,8 @@ static debug_type *stab_demangle_argtype
   (void *, struct stab_handle *, const char *, bfd_boolean *, unsigned int);
 static debug_type *stab_demangle_v3_argtypes
   (void *, struct stab_handle *, const char *, bfd_boolean *);
+static debug_type *stab_demangle_v3_arglist
+  (void *, struct stab_handle *, struct demangle_component *, bfd_boolean *);
 static debug_type stab_demangle_v3_arg
   (void *, struct stab_handle *, struct demangle_component *, debug_type,
    bfd_boolean *);
@@ -5073,7 +5075,6 @@ stab_demangle_v3_argtypes (void *dhandle
 {
   struct demangle_component *dc;
   void *mem;
-  unsigned int alloc, count;
   debug_type *pargs;
 
   dc = cplus_demangle_v3_components (physname, DMGL_PARAMS | DMGL_ANSI, &mem);
@@ -5093,13 +5094,35 @@ stab_demangle_v3_argtypes (void *dhandle
       return NULL;
     }
 
+  pargs = stab_demangle_v3_arglist (dhandle, info,
+				    dc->u.s_binary.right->u.s_binary.right,
+				    pvarargs);
+
+  free (mem);
+
+  return pargs;
+}
+
+/* Demangle an argument list in a struct demangle_component tree.
+   Returns a DEBUG_TYPE_NULL terminated array of argument types, and
+   sets *PVARARGS to indicate whether this is a varargs function.  */
+
+static debug_type *
+stab_demangle_v3_arglist (void *dhandle, struct stab_handle *info,
+			  struct demangle_component *arglist,
+			  bfd_boolean *pvarargs)
+{
+  struct demangle_component *dc;
+  unsigned int alloc, count;
+  debug_type *pargs;
+
   alloc = 10;
   pargs = (debug_type *) xmalloc (alloc * sizeof *pargs);
   *pvarargs = FALSE;
 
   count = 0;
 
-  for (dc = dc->u.s_binary.right->u.s_binary.right;
+  for (dc = arglist;
        dc != NULL;
        dc = dc->u.s_binary.right)
     {
@@ -5108,8 +5131,8 @@ stab_demangle_v3_argtypes (void *dhandle
 
       if (dc->type != DEMANGLE_COMPONENT_ARGLIST)
 	{
-	  fprintf (stderr, _("Unexpected type in demangle tree\n"));
-	  free (mem);
+	  fprintf (stderr, _("Unexpected type in v3 arglist demangling\n"));
+	  free (pargs);
 	  return NULL;
 	}
 
@@ -5122,7 +5145,7 @@ stab_demangle_v3_argtypes (void *dhandle
 	      *pvarargs = TRUE;
 	      continue;
 	    }
-	  free (mem);
+	  free (pargs);
 	  return NULL;
 	}
 
@@ -5138,8 +5161,6 @@ stab_demangle_v3_argtypes (void *dhandle
 
   pargs[count] = DEBUG_TYPE_NULL;
 
-  free (mem);
-
   return pargs;
 }
 
@@ -5173,12 +5194,12 @@ stab_demangle_v3_arg (void *dhandle, str
     case DEMANGLE_COMPONENT_COMPLEX:
     case DEMANGLE_COMPONENT_IMAGINARY:
     case DEMANGLE_COMPONENT_VENDOR_TYPE:
-    case DEMANGLE_COMPONENT_FUNCTION_TYPE:
     case DEMANGLE_COMPONENT_ARRAY_TYPE:
     case DEMANGLE_COMPONENT_PTRMEM_TYPE:
     case DEMANGLE_COMPONENT_ARGLIST:
     default:
-      fprintf (stderr, _("Unrecognized demangle component\n"));
+      fprintf (stderr, _("Unrecognized demangle component %d\n"),
+	       (int) dc->type);
       return NULL;
 
     case DEMANGLE_COMPONENT_NAME:
@@ -5269,6 +5290,34 @@ stab_demangle_v3_arg (void *dhandle, str
 	  return debug_make_reference_type (dhandle, dt);
 	}
 
+    case DEMANGLE_COMPONENT_FUNCTION_TYPE:
+      {
+	debug_type *pargs;
+	bfd_boolean varargs;
+
+	if (dc->u.s_binary.left == NULL)
+	  {
+	    /* In this case the return type is actually unknown.
+	       However, I'm not sure this will ever arise in practice;
+	       normally an unknown return type would only appear at
+	       the top level, which is handled above.  */
+	    dt = debug_make_void_type (dhandle);
+	  }
+	else
+	  dt = stab_demangle_v3_arg (dhandle, info, dc->u.s_binary.left, NULL,
+				     NULL);
+	if (dt == NULL)
+	  return NULL;
+
+	pargs = stab_demangle_v3_arglist (dhandle, info,
+					  dc->u.s_binary.right,
+					  &varargs);
+	if (pargs == NULL)
+	  return NULL;
+
+	return debug_make_function_type (dhandle, dt, pargs, varargs);
+      }
+
     case DEMANGLE_COMPONENT_BUILTIN_TYPE:
       {
 	char *p;