Introduce OP_VAR_MSYM_VALUE

The previous patch left GDB with an inconsistency.  While with normal
expression evaluation the "unknown return type" error shows the name
of the function that misses debug info:

  (gdb) p getenv ("PATH")
  'getenv' has unknown return type; cast the call to its declared return type
   ^^^^^^

which can by handy in more complicated expressions, "ptype" does not:

  (gdb) ptype getenv ("PATH")
  function has unknown return type; cast the call to its declared return type
  ^^^^^^^^

This commit is a step toward fixing it.

The problem is that while evaluating the expression above, we have no
reference to the minimal symbol where we could extract the name from.
This is because the resulting expression tree has no reference to the
minsym at all.  During parsing, the type and address of the minsym are
extracted and an UNOP_MEMVAL / UNOP_MEMVAL_TLS operator is generated
(see write_exp_elt_msym).  With "set debug expression", here's what
you see:

            0  OP_FUNCALL            Number of args: 0
            3    UNOP_MEMVAL           Type @0x565334a51930 (<text variable, no debug info>)
            6      OP_LONG               Type @0x565334a51c60 (__CORE_ADDR), value 140737345035648 (0x7ffff7751d80)

The "print" case finds the function name, because
call_function_by_hand looks up the function by address again.
However, for "ptype", we don't reach that code, because obviously we
don't really call the function.

Unlike minsym references, references to variables with debug info have
a pointer to the variable's symbol in the expression tree, with
OP_VAR_VALUE:

  (gdb) ptype main()
  ...
            0  OP_FUNCALL            Number of args: 0
            3    OP_VAR_VALUE          Block @0x0, symbol @0x559bbbd9b358 (main(int, char**))
  ...

so I don't see why do minsyms need to be different.  So to prepare for
fixing the missing function name issue, this commit adds a new
OP_VAR_MSYM_VALUE operator that mimics OP_VAR_VALUE, except that it's
for minsyms instead of debug symbols.  For infcalls, we now get
expressions like these:

            0  OP_FUNCALL            Number of args: 0
            3    OP_VAR_MSYM_VALUE     Objfile @0x1e41bf0, msymbol @0x7fffe599b000 (getenv)

In the following patch, we'll make OP_FUNCALL extract the function
name from the symbol stored in OP_VAR_VALUE/OP_VAR_MSYM_VALUE.

OP_VAR_MSYM_VALUE will be used more in a later patch in the series
too.

gdb/ChangeLog:
2017-09-04  Pedro Alves  <palves@redhat.com>

	* ada-lang.c (resolve_subexp): Handle OP_VAR_MSYM_VALUE.
	* ax-gdb.c (gen_msym_var_ref): New function.
	(gen_expr): Handle OP_VAR_MSYM_VALUE.
	* eval.c (evaluate_var_msym_value): New function.
	* eval.c (evaluate_subexp_standard): Handle OP_VAR_MSYM_VALUE.
	<OP_FUNCALL>: Extract function name from symbol/minsym and pass it
	to call_function_by_hand.
	* expprint.c (print_subexp_standard, dump_subexp_body_standard):
	Handle OP_VAR_MSYM_VALUE.
	(union exp_element) <msymbol>: New field.
	* minsyms.h (struct type): Forward declare.
	(find_minsym_type_and_address): Declare.
	* parse.c (write_exp_elt_msym): New function.
	(write_exp_msymbol): Delete, refactored as ...
	(find_minsym_type_and_address): ... this new function.
	(write_exp_msymbol): Reimplement using OP_VAR_MSYM_VALUE.
	(operator_length_standard, operator_check_standard): Handle
	OP_VAR_MSYM_VALUE.
	* std-operator.def (OP_VAR_MSYM_VALUE): New.

1 files changed, 1 insertions, 0 deletions

diff --git a/gdb/expression.h b/gdb/expression.h
index 8fe6b07..9e4ddf5 100644
--- a/gdb/expression.h
+++ b/gdb/expression.h
@@ -64,6 +64,7 @@ union exp_element
   {
     enum exp_opcode opcode;
     struct symbol *symbol;
+    struct minimal_symbol *msymbol;
     LONGEST longconst;
     DOUBLEST doubleconst;
     gdb_byte decfloatconst[16];