This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]