From: Andrew Cagney <ac131313@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: [patch/rfc] Better handle "void f()" et.al. returns
Date: Mon, 17 Nov 2003 20:50:00 -0000 [thread overview]
Message-ID: <3FB934A8.2030009@redhat.com> (raw)
[-- 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))
{
next reply other threads:[~2003-11-17 20:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-17 20:50 Andrew Cagney [this message]
2003-11-19 16:27 ` Andrew Cagney
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=3FB934A8.2030009@redhat.com \
--to=ac131313@redhat.com \
--cc=gdb-patches@sources.redhat.com \
/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