[patch/rfc] Better handle "void f()" et.al. returns

[patch/rfc] Better handle "void f()" et.al. returns

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]

Hello,

It turns out that how return values for a void function was handled was 
largely pot-luck.  PPC, for instance, treated it as "in register" while 
PPC64 treated it as "in memory".  Dependant on the choice (e.g., the 
latter), the mysterious message:

	(gdb) print foo()
	Attempt to dereference a generic pointer.
	(gdb)

would appear.  This patch cleans up the "return" (and "finish") code so 
that it better handles the edge cases:

	- function returning void
	- function returning struct (old gdb architecture)
	- function using struct convention

and at the same time prints more informative messages vis:

(gdb) return foo16
The location at which to store the function's return value is unknown.
If you continue, the return value that you specified will be ignored.
Make fun16 return now? (y or n)

or

(gdb) return foo16
A structure or union return type is not supported by this architecture.
If you continue, the return value that you specified will be ignored.

Baring comments, I'll commit this in a day or so,
Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 3979 bytes --]

2003-11-17  Andrew Cagney  <cagney@redhat.com>

	* stack.c (return_command): Handle "void", "legacy" and "unknown
	location" return values separatly.
	* values.c (using_struct_return): Return 0 for a "void" return
	type.  Mention "register_value_being_returned".
	(register_value_being_returned): Mention "using_struct_return".

Index: stack.c
===================================================================
RCS file: /cvs/src/src/gdb/stack.c,v
retrieving revision 1.95
diff -u -r1.95 stack.c
--- stack.c	10 Nov 2003 22:47:28 -0000	1.95
+++ stack.c	17 Nov 2003 20:28:18 -0000
@@ -1854,33 +1854,33 @@
       if (VALUE_LAZY (return_value))
 	value_fetch_lazy (return_value);
 
-      /* Check that this architecture can handle the function's return
-         type.  In the case of "struct convention", still do the
-         "return", just also warn the user.  */
-      if (gdbarch_return_value_p (current_gdbarch))
+      if (TYPE_CODE (return_type) == TYPE_CODE_VOID)
+	/* If the return-type is "void", don't try to find the
+           return-value's location.  However, do still evaluate the
+           return expression so that, even when the expression result
+           is discarded, side effects such as "return i++" still
+           occure.  */
+	return_value = NULL;
+      else if (!gdbarch_return_value_p (current_gdbarch)
+	       && (TYPE_CODE (return_type) == TYPE_CODE_STRUCT
+		   || TYPE_CODE (return_type) == TYPE_CODE_UNION))
 	{
-	  if (gdbarch_return_value (current_gdbarch, return_type,
-				    NULL, NULL, NULL)
-	      == RETURN_VALUE_STRUCT_CONVENTION)
-	    return_value = NULL;
+	  /* NOTE: cagney/2003-10-20: Compatibility hack for legacy
+	     code.  Old architectures don't expect STORE_RETURN_VALUE
+	     to be called with with a small struct that needs to be
+	     stored in registers.  Don't start doing it now.  */
+	  query_prefix = "\
+A structure or union return type is not supported by this architecture.\n\
+If you continue, the return value that you specified will be ignored.\n";
+	  return_value = NULL;
 	}
-      else
+      else if (using_struct_return (return_type, 0))
 	{
-	  /* NOTE: cagney/2003-10-20: The double check is to ensure
-	     that the STORE_RETURN_VALUE call, further down, is not
-	     applied to a struct or union return-value.  It wasn't
-	     allowed previously, so don't start allowing it now.  An
-	     ABI that uses "register convention" to return small
-	     structures and should implement the "return_value"
-	     architecture method.  */
-	  if (using_struct_return (return_type, 0)
-	      || TYPE_CODE (return_type) == TYPE_CODE_STRUCT
-	      || TYPE_CODE (return_type) == TYPE_CODE_UNION)
-	    return_value = NULL;
+	  query_prefix = "\
+The location at which to store the function's return value is unknown.\n\
+If you continue, the return value that you specified will be ignored.\n";
+	  return_value = NULL;
 	}
-      if (return_value == NULL)
-	query_prefix = "\
-The location at which to store the function's return value is unknown.\n";
     }
 
   /* Does an interactive user really want to do this?  Include
Index: values.c
===================================================================
RCS file: /cvs/src/src/gdb/values.c,v
retrieving revision 1.62
diff -u -r1.62 values.c
--- values.c	10 Nov 2003 22:47:28 -0000	1.62
+++ values.c	17 Nov 2003 20:28:18 -0000
@@ -1223,7 +1223,7 @@
   struct value *val = allocate_value (valtype);
 
   /* If the function returns void, don't bother fetching the return
-     value.  */
+     value.  See also "using_struct_return".  */
   if (TYPE_CODE (valtype) == TYPE_CODE_VOID)
     return val;
 
@@ -1284,6 +1284,11 @@
 
   if (code == TYPE_CODE_ERROR)
     error ("Function return type unknown.");
+
+  if (code == TYPE_CODE_VOID)
+    /* A void return value is never in memory.  See also corresponding
+       code in "register_value_being_returned".  */
+    return 0;
 
   if (!gdbarch_return_value_p (current_gdbarch))
     {

Re: [patch/rfc] Better handle "void f()" et.al. returns

[Andrew Cagney]

> Hello,
> 
> It turns out that how return values for a void function was handled was largely pot-luck.  PPC, for instance, treated it as "in register" while PPC64 treated it as "in memory".  Dependant on the choice (e.g., the latter), the mysterious message:
> 
>     (gdb) print foo()
>     Attempt to dereference a generic pointer.
>     (gdb)
> 
> would appear.  This patch cleans up the "return" (and "finish") code so that it better handles the edge cases:
> 
>     - function returning void
>     - function returning struct (old gdb architecture)
>     - function using struct convention
> 
> and at the same time prints more informative messages vis:
> 
> (gdb) return foo16
> The location at which to store the function's return value is unknown.
> If you continue, the return value that you specified will be ignored.
> Make fun16 return now? (y or n)
> 
> or
> 
> (gdb) return foo16
> A structure or union return type is not supported by this architecture.
> If you continue, the return value that you specified will be ignored.

I've checked this in.

Andrew


> 2003-11-17  Andrew Cagney  <cagney@redhat.com>
> 
> 	* stack.c (return_command): Handle "void", "legacy" and "unknown
> 	location" return values separatly.
> 	* values.c (using_struct_return): Return 0 for a "void" return
> 	type.  Mention "register_value_being_returned".
> 	(register_value_being_returned): Mention "using_struct_return".
>