[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.

palves at redhat dot com sourceware-bugzilla@sourceware.org
Tue Jun 13 09:50:00 GMT 2017


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

--- Comment #12 from Pedro Alves <palves at redhat dot com> ---
On 06/13/2017 01:01 AM, keiths at redhat dot com wrote:
> 
>  <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     

Hmm, constprop here might well be related.  This is:

 $ echo _ZN5Shell6TinySh7char_inEc.constprop.67 | c++filt 
 Shell::TinySh::char_in(char) [clone .constprop.67]

I think that means that the compiler cloned the "char_in(char)"
function, constant-propagated some argument in that clone.

I'd guess it decided the char_in function does not use the "this" pointer
for anything, and got rid of it in the clone?  And then the compiler's
debug info emission code gets confused and always emits the first
parameter as artificial, even though it's no longer the "this"
hidden arg?  Just guessing.

Or could maybe "Shell::TinySh::char_in(char)" be really
a static method, and the "char" parameter ends up marked
artificial because that's what the compiler "const propagated"?
I.e., that parameter doesn't really exist in the generated code?

It'd be good to know what exactly was "Shell::TinySh::char_in(char)"
compiled from -- free function, method, static method?  Etc.

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


More information about the Gdb-prs mailing list