[Bug gdb/21549] c-typeprint.c:262: internal-error: void cp_type_print_method_args(type*, const char*, const char*, int, ui_file*, const type_print_options*): Assertion `TYPE_CODE (args[0].type) == TYPE_CODE_PTR' failed.

["keiths at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21549

--- Comment #11 from Keith Seitz <keiths at redhat dot com> ---
(In reply to Keith Seitz from comment #10)
> From what I can infer from this, GDB (erroneously) marks cmd_help as a
> non-static member function, but it's really just a guess.

Red herring. Ignore my previous comment.

I built up an arm-none-eabi-gdb and was able to easily step through the code. A
simple "ptype Shell::TinySh" triggers the assertion.

The symbol we actually falter on is the one in DIE 0xa013:

 <3><a013>: Abbrev Number: 53 (DW_TAG_subprogram)
    <a014>   DW_AT_external    : 1      
    <a014>   DW_AT_name        : (indirect string, offset: 0x2806):
_ZN5Shell6TinySh7char_inEc.constprop.67     
    <a018>   DW_AT_decl_file   : 9      
    <a019>   DW_AT_decl_line   : 487    
    <a01b>   DW_AT_accessibility: 3     (private)
    <a01c>   DW_AT_declaration : 1      
    <a01c>   DW_AT_sibling     : <0xa026>       
 <4><a020>: Abbrev Number: 11 (DW_TAG_formal_parameter)
    <a021>   DW_AT_type        : <0x9630>       
    <a025>   DW_AT_artificial  : 1      
 <4><a025>: Abbrev Number: 0

>From this, we see the `this' pointer (properly marked artificial) has type
given by 0x9630:

 <1><9630>: Abbrev Number: 2 (DW_TAG_base_type)
    <9631>   DW_AT_byte_size   : 1      
    <9632>   DW_AT_encoding    : 8      (unsigned char)
    <9633>   DW_AT_name        : (indirect string, offset: 0x30fd): char        

Yup. The `this' pointer is of type `char'. That is clearly really bad. [I don't
know if this is a linking problem or a compiler problem -- I've never seen
DW_AT_name like the one listed above).

I don't know if we really want to "fix" this, it is showing a pretty serious
error somewhere. However, if you wanted to workaround this, I would modify
cp_type_print_method_args:

diff --git a/gdb/c-typeprint.c b/gdb/c-typeprint.c
index 5a23e92..dafc080 100644
--- a/gdb/c-typeprint.c
+++ b/gdb/c-typeprint.c
@@ -641,27 +641,27 @@ cp_type_print_method_args (struct type *mtype, const char
*prefix,
      THIS.  */
   if (!staticp)
     {
-      struct type *domain;
-
       gdb_assert (nargs > 0);
-      gdb_assert (TYPE_CODE (args[0].type) == TYPE_CODE_PTR);
-      domain = TYPE_TARGET_TYPE (args[0].type);

-      if (TYPE_CONST (domain))
-       fprintf_filtered (stream, " const");
+      if (TYPE_CODE (args[0].type) == TYPE_CODE_PTR)
+       {
+         struct type *domain = TYPE_TARGET_TYPE (args[0].type);
+
+         if (TYPE_CONST (domain))
+           fprintf_filtered (stream, " const");

-      if (TYPE_VOLATILE (domain))
-       fprintf_filtered (stream, " volatile");
+         if (TYPE_VOLATILE (domain))
+           fprintf_filtered (stream, " volatile");

-      if (TYPE_RESTRICT (domain))
-       fprintf_filtered (stream, " restrict");
+         if (TYPE_RESTRICT (domain))
+           fprintf_filtered (stream, " restrict");

-      if (TYPE_ATOMIC (domain))
-       fprintf_filtered (stream, " _Atomic");
+         if (TYPE_ATOMIC (domain))
+           fprintf_filtered (stream, " _Atomic");
+       }
     }
 }

-
 /* Print any asterisks or open-parentheses needed before the
    variable name (to describe its type).

[That's mostly whitespace change.]

That will get you going again while I discuss with maintainers what we should
do.

-- 
You are receiving this mail because:
You are on the CC list for the bug.