public inbox for gdb-testers@sourceware.org help / color / mirror / Atom feed
From: sergiodj+buildbot@sergiodj.net To: gdb-testers@sourceware.org Subject: [binutils-gdb] Make "p S::method() const::static_var" work too Date: Tue, 05 Sep 2017 01:38:00 -0000 [thread overview] Message-ID: <3693fdb3c8ec14bd8ecb4ebb39e4384b330a2999@gdb-build> (raw) *** TEST RESULTS FOR COMMIT 3693fdb3c8ec14bd8ecb4ebb39e4384b330a2999 *** Author: Pedro Alves <palves@redhat.com> Branch: master Commit: 3693fdb3c8ec14bd8ecb4ebb39e4384b330a2999 Make "p S::method() const::static_var" work too Trying to print a function local static variable of a const-qualified method still doesn't work after the previous fixes: (gdb) p 'S::method() const'::static_var $1 = {i1 = 1, i2 = 2, i3 = 3} (gdb) p S::method() const::static_var No symbol "static_var" in specified context. The reason is that the expression parser/evaluator loses the "const", and the above unquoted case is just like trying to print a variable of the non-const overload, if it exists, even. As if the above unquoted case had been written as: (gdb) p S::method()::static_var No symbol "static_var" in specified context. We can see the problem without static vars in the picture. With: struct S { void method (); void method () const; }; Compare: (gdb) print 'S::method(void) const' $1 = {void (const S * const)} 0x400606 <S::method() const> (gdb) print S::method(void) const $2 = {void (S * const)} 0x4005d8 <S::method()> # wrong method! That's what we need to fix. If we fix that, the function local static case starts working. The grammar production for function/method types is this one: exp: exp '(' parameter_typelist ')' const_or_volatile This results in a TYPE_INSTANCE expression evaluator operator. For the example above, we get something like this ("set debug expression 1"): ... 0 TYPE_INSTANCE 1 TypeInstance: Type @0x560fda958be0 (void) 5 OP_SCOPE Type @0x560fdaa544d8 (S) Field name: `method' ... While evaluating TYPE_INSTANCE, we end up in value_struct_elt_for_reference, trying to find the method named "method" that has the prototype recorded in TYPE_INSTANCE. In this case, TYPE_INSTANCE says that we're looking for a method that has "(void)" as parameters (that's what "1 TypeInstance: Type @0x560fda958be0 (void)" above means. The trouble is that nowhere in this mechanism do we communicate to value_struct_elt_for_reference that we're looking for the _const_ overload. value_struct_elt_for_reference only compared parameters, and the non-const "method()" overload has matching parameters, so it's considered the right match... Conveniently, the "const_or_volatile" production in the grammar already records "const" and "volatile" info in the type stack. The type stack is not used in this code path, but we can borrow the information. The patch converts the info in the type stack to an "instance flags" enum, and adds that as another element in TYPE_INSTANCE operators. This type instance flags is then applied to the temporary type that is passed to value_struct_elt_for_reference for matching. The other side of the problem is that methods in the debug info aren't marked const/volatile, so with that in place, the matching never finds const/volatile-qualified methods. The problem is that in the DWARF, there's no indication at all whether a method is const/volatile qualified... For example (c++filt applied to the linkage name for convenience): <2><d3>: Abbrev Number: 6 (DW_TAG_subprogram) <d4> DW_AT_external : 1 <d4> DW_AT_name : (indirect string, offset: 0x3df): method <d8> DW_AT_decl_file : 1 <d9> DW_AT_decl_line : 58 <da> DW_AT_linkage_name: (indirect string, offset: 0x5b2): S::method() const <de> DW_AT_declaration : 1 <de> DW_AT_object_pointer: <0xe6> <e2> DW_AT_sibling : <0xec> I see the same with both GCC and Clang. The patch works around this by extracting the cv qualification from the "const" and "volatile" in the demangled name. This will need further tweaking for "&" and "const &" overloads, but we don't support them in the parser yet, anyway. The TYPE_CONST changes were necessary otherwise the comparisons in valops.c: if (TYPE_CONST (intype) != TYPE_FN_FIELD_CONST (f, j)) continue; would fail, because when both TYPE_CONST() TYPE_FN_FIELD_CONST() were true, their values were different. BTW, I'm recording the const/volatile-ness of methods in the TYPE_FN_FIELD info because #1 - I'm not sure it's kosher to change the method's type directly (vs having to call make_cv_type to create a new type), and #2 it's what stabsread.c does: ... case 'A': /* Normal functions. */ new_sublist->fn_field.is_const = 0; new_sublist->fn_field.is_volatile = 0; (*pp)++; break; case 'B': /* `const' member functions. */ new_sublist->fn_field.is_const = 1; new_sublist->fn_field.is_volatile = 0; ... After all this, this finally all works: print S::method(void) const $1 = {void (const S * const)} 0x400606 <S::method() const> (gdb) p S::method() const::static_var $2 = {i1 = 1, i2 = 2, i3 = 3} gdb/ChangeLog: 2017-09-04 Pedro Alves <palves@redhat.com> * c-exp.y (function_method, function_method_void): Add current instance flags to TYPE_INSTANCE. * dwarf2read.c (check_modifier): New. (compute_delayed_physnames): Assert that only C++ adds delayed physnames. Mark fn_fields as const/volatile depending on physname. * eval.c (make_params): New type_instance_flags parameter. Use it as the new type's instance flags. (evaluate_subexp_standard) <TYPE_INSTANCE>: Extract the instance flags element and pass it to make_params. * expprint.c (print_subexp_standard) <TYPE_INSTANCE>: Handle instance flags element. (dump_subexp_body_standard) <TYPE_INSTANCE>: Likewise. * gdbtypes.h: Include "enum-flags.h". (type_instance_flags): New enum-flags type. (TYPE_CONST, TYPE_VOLATILE, TYPE_RESTRICT, TYPE_ATOMIC) (TYPE_CODE_SPACE, TYPE_DATA_SPACE): Return boolean. * parse.c (operator_length_standard) <TYPE_INSTANCE>: Adjust. (follow_type_instance_flags): New function. (operator_check_standard) <TYPE_INSTANCE>: Adjust. * parser-defs.h (follow_type_instance_flags): Declare. * valops.c (value_struct_elt_for_reference): const/volatile must match too. gdb/testsuite/ChangeLog: 2017-09-04 Pedro Alves <palves@redhat.com> * gdb.base/func-static.c (S::method const, S::method volatile) (S::method volatile const): New methods. (c_s, v_s, cv_s): New instances. (main): Call method() on them. * gdb.base/func-static.exp (syntax_re, cannot_resolve_re): New variables. (cannot_resolve): New procedure. (cxx_scopes_list): Test cv methods. Add print-scope-quote and print-quote-unquoted columns. (do_test): Test printing each scope too.
next reply other threads:[~2017-09-05 1:02 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-09-05 1:38 sergiodj+buildbot [this message] 2017-09-05 4:27 ` *** COMPILATION FAILED *** Failures on Fedora-x86_64-cc-with-index, branch master *** BREAKAGE *** sergiodj+buildbot 2017-09-05 4:27 ` *** COMPILATION FAILED *** Failures on Fedora-x86_64-native-gdbserver-m64, " sergiodj+buildbot 2017-09-05 4:32 ` *** COMPILATION FAILED *** Failures on Fedora-i686, " sergiodj+buildbot 2017-09-05 4:35 ` *** COMPILATION FAILED *** Failures on Fedora-x86_64-native-extended-gdbserver-m64, " sergiodj+buildbot 2017-09-05 12:03 ` *** COMPILATION FAILED *** Failures on Ubuntu-AArch32-native-extended-gdbserver-m32, " sergiodj+buildbot 2017-09-05 12:10 ` *** COMPILATION FAILED *** Failures on Ubuntu-AArch32-native-gdbserver-m32, " sergiodj+buildbot 2017-09-05 12:21 ` *** COMPILATION FAILED *** Failures on Ubuntu-AArch32-m32, " sergiodj+buildbot
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3693fdb3c8ec14bd8ecb4ebb39e4384b330a2999@gdb-build \ --to=sergiodj+buildbot@sergiodj.net \ --cc=gdb-testers@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).