Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: gdb-patches@sourceware.org
Subject: [PATCH 03/13] Make ptype/whatis print function name of functions with no debug info too
Date: Thu, 13 Jul 2017 02:19:00 -0000	[thread overview]
Message-ID: <1499912370-1842-4-git-send-email-palves@redhat.com> (raw)
In-Reply-To: <1499912370-1842-1-git-send-email-palves@redhat.com>

The patch to make GDB stop assuming functions return int 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 is 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 builds on the new OP_VAR_MSYM_VALUE to fix it, by making
OP_FUNCALL extract the function name from the symbol stored in
OP_VAR_VALUE/OP_VAR_MSYM_VALUE.  We now get the same error in "print"
vs "ptype":

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

gdb/ChangeLog:
yyyy-dd-yy  Pedro Alves  <palves@redhat.com>

	* eval.c (evaluate_subexp_standard): <OP_FUNCALL>: Extract
	function name from symbol/minsym and pass it to
	error_call_unknown_return_type.

gdb/testsuite/ChangeLog:
yyyy-dd-yy  Pedro Alves  <palves@redhat.com>

	* gdb.base/nodebug.exp: Test that ptype's error about functions
	with unknown return type includes the function name too.
---
 gdb/eval.c                         | 14 +++++++++++++-
 gdb/testsuite/gdb.base/nodebug.exp | 12 ++++--------
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/gdb/eval.c b/gdb/eval.c
index 457e280..0e77f0a 100644
--- a/gdb/eval.c
+++ b/gdb/eval.c
@@ -716,6 +716,7 @@ evaluate_subexp_standard (struct type *expect_type,
   int save_pos1;
   struct symbol *function = NULL;
   char *function_name = NULL;
+  const char *var_func_name = NULL;
 
   pc = (*pos)++;
   op = exp->elts[pc].opcode;
@@ -1545,6 +1546,17 @@ evaluate_subexp_standard (struct type *expect_type,
 	    }
 	  else
 	    {
+	      if (op == OP_VAR_MSYM_VALUE)
+		{
+		  symbol *sym = exp->elts[*pos + 2].symbol;
+		  var_func_name = SYMBOL_PRINT_NAME (sym);
+		}
+	      else if (op == OP_VAR_VALUE)
+		{
+		  minimal_symbol *msym = exp->elts[*pos + 2].msymbol;
+		  var_func_name = MSYMBOL_PRINT_NAME (msym);
+		}
+
 	      argvec[0] = evaluate_subexp_with_coercion (exp, pos, noside);
 	      type = value_type (argvec[0]);
 	      if (type && TYPE_CODE (type) == TYPE_CODE_PTR)
@@ -1761,7 +1773,7 @@ evaluate_subexp_standard (struct type *expect_type,
 		return_type = expect_type;
 
 	      if (return_type == NULL)
-		error_call_unknown_return_type (NULL);
+		error_call_unknown_return_type (var_func_name);
 
 	      return allocate_value (return_type);
 	    }
diff --git a/gdb/testsuite/gdb.base/nodebug.exp b/gdb/testsuite/gdb.base/nodebug.exp
index 25dbf63..e7a6774 100644
--- a/gdb/testsuite/gdb.base/nodebug.exp
+++ b/gdb/testsuite/gdb.base/nodebug.exp
@@ -165,14 +165,10 @@ if [runto inner] then {
     
     # This test is not as obscure as it might look.  `p getenv ("TERM")'
     # is a real-world example, at least on many systems.
-
-    gdb_test {p/c array_index("abcdef",2)} \
-	"'array_index' has unknown return type; cast the call to its declared return type"
-    gdb_test {ptype array_index("abcdef",2)} \
-	"function has unknown return type; cast the call to its declared return type"
-    gdb_test {whatis array_index("abcdef",2)} \
-	"function has unknown return type; cast the call to its declared return type"
-
+    foreach cmd {"p/c" "ptype" "whatis"} {
+	gdb_test "$cmd array_index(\"abcdef\",2)" \
+	    "'array_index' has unknown return type; cast the call to its declared return type"
+    }
     if [target_info exists gdb,cannot_call_functions] {
 	unsupported "p/c (int) array_index(\"abcdef\",2)"
     } else {
-- 
2.5.5


  parent reply	other threads:[~2017-07-13  2:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-13  2:19 [PATCH 00/13] No-debug-info debugging improvements Pedro Alves
2017-07-13  2:19 ` [PATCH 02/13] Introduce OP_VAR_MSYM_VALUE Pedro Alves
2017-07-13  2:19 ` [PATCH 01/13] Stop assuming no-debug-info functions return int Pedro Alves
2017-07-13  2:19 ` [PATCH 07/13] Stop assuming no-debug-info variables have type int Pedro Alves
2017-07-13  2:19 ` [PATCH 08/13] Eliminate UNOP_MEMVAL_TLS Pedro Alves
2017-07-13  2:19 ` Pedro Alves [this message]
2017-07-13  2:19 ` [PATCH 04/13] evaluate_subexp_standard: Eliminate one goto Pedro Alves
2017-07-13  2:27 ` [PATCH 06/13] evaluate_subexp_standard: Factor out OP_VAR_VALUE handling Pedro Alves
2017-07-13  2:27 ` [PATCH 09/13] Handle "p S::method()::static_var" in the C++ parser Pedro Alves
2017-07-13  2:28 ` [PATCH 05/13] evaluate_subexp_standard: Remove useless assignments Pedro Alves
2017-07-13  2:28 ` [PATCH 11/13] Make "p S::method() const::static_var" work too Pedro Alves
2017-07-13  2:28 ` [PATCH 12/13] Document "no debug info debugging" improvements Pedro Alves
2017-07-13 11:09   ` [PATCH 13/13] " Pedro Alves
2017-07-13 13:51     ` Pedro Alves
2017-07-13 13:54       ` Pedro Alves
2017-07-13 15:33         ` Pedro Alves
2017-07-13 15:47   ` [PATCH 12/13] " Eli Zaretskii
2017-07-13 16:14     ` Pedro Alves
2017-07-13  2:29 ` [PATCH 12/13] Fix calling prototyped functions via function pointers Pedro Alves
2017-07-13  2:29 ` [PATCH 10/13] Handle "p 'S::method()::static_var'" (quoted) in symbol lookup Pedro Alves

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=1499912370-1842-4-git-send-email-palves@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@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