From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25822 invoked by alias); 17 Nov 2003 20:50:54 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25788 invoked from network); 17 Nov 2003 20:50:52 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 17 Nov 2003 20:50:52 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8F67D2B8F for ; Mon, 17 Nov 2003 15:50:48 -0500 (EST) Message-ID: <3FB934A8.2030009@redhat.com> Date: Mon, 17 Nov 2003 20:50:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: [patch/rfc] Better handle "void f()" et.al. returns Content-Type: multipart/mixed; boundary="------------060300010801020706090005" X-SW-Source: 2003-11/txt/msg00361.txt.bz2 This is a multi-part message in MIME format. --------------060300010801020706090005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1033 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 --------------060300010801020706090005 Content-Type: text/plain; name="diffs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diffs" Content-length: 3979 2003-11-17 Andrew Cagney * 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)) { --------------060300010801020706090005--