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.


             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: link
Be 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).