From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9302 invoked by alias); 12 Mar 2002 10:38:32 -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 9145 invoked from network); 12 Mar 2002 10:38:24 -0000 Received: from unknown (HELO mail-out1.apple.com) (17.254.0.52) by sources.redhat.com with SMTP; 12 Mar 2002 10:38:24 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g2CAcMQ23570 for ; Tue, 12 Mar 2002 02:38:23 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 12 Mar 2002 02:38:22 -0800 Received: from molly.localnet (vpn-scv-x2-209.apple.com [17.219.193.209]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g2CAcCb11807; Tue, 12 Mar 2002 02:38:13 -0800 (PST) Date: Tue, 12 Mar 2002 02:38:00 -0000 Subject: Re: [RFA] Function return type checking Content-Type: multipart/alternative; boundary=Apple-Mail-1--1032422154 Mime-Version: 1.0 (Apple Message framework v481) Cc: Klee Dienes , Daniel Jacobowitz , gdb-patches@sources.redhat.com To: Andrew Cagney From: Klee Dienes In-Reply-To: <3C8AE16D.9000502@cygnus.com> Message-Id: <3B4ED0FE-35A5-11D6-A901-0030653FA4C6@apple.com> X-Mailer: Apple Mail (2.481) X-SW-Source: 2002-03/txt/msg00178.txt.bz2 --Apple-Mail-1--1032422154 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Content-length: 3091 On Saturday, March 9, 2002, at 08:30 PM, Andrew Cagney wrote: > I've personally got reservations over introducing a change that, given > a file like: > > void > b(void) > { > double d; > d = (double) bar ((float) 3); > } > > radically alters gdb's behavour given: > > print (double) bar((float) 3) > > and rejects (?) > > print bar((float) 3) I think that's a very valid reservation. But let me expand the example a bit: $ cat a.c double foo (float f) { return (f + 1.0); } double bar (float f) { return (f + 1.0); } $ cat b.c double foo (float); int main () { double d1, d2; d1 = (double) foo ((float) 3); d2 = (double) bar ((float) 3); } $ cc -c a.c $ cc -g -c b.c $ cc a.o b.o -o a In "standard" GDB, you get the following results: (gdb) print d1 $1 = 4 (gdb) print d2 $2 = 1 /* generic bogus value */ (gdb) print (double) foo ((float) 3) $3 = 1 /* generic bogus value */ (gdb) print (double) bar ((float) 3) $4 = 1 /* generic bogus value */ In GDB as patched, you get: (gdb) print d1 $1 = 4 (gdb) print d2 $2 = 1074266112 /* generic bogus value */ (gdb) print (double) foo ((float) 3) $3 = 4 (gdb) print (double) bar ((float) 3) $4 = 4 I'd argue that the real problem here is that the calling conventions for a function call are determined for GCC and for GDB in two very different ways. In the case of GCC, it's based on what signature GCC has seen for the function. In the case of GDB, it's based on what debugging information is available for the function being called. This means that it's always going to be possible for there to be a mismatch between behavior of GCC and GDB when evaluating expressions, and my patch does not try to address that. My patch only changes the default behavior from two "incorrect" results (only one of which matches the behavior of GCC), to two "correct" results (only one of which matches the behavior of GCC). I'd argue that it's better to err on the side of returning the correct result, if you have to err at all, and that in the case where you do want the exact behavior of GCC, print (float) (int) bar ((float) 3) is much more intuitive and easy to type than print ((float (*) ()) bar) ((float) 3) > and rejects (?) > > print bar((float) 3) Correct; this would print: Unable to call function at 0x1df8: no return type information available. To call this function anyway, you can cast the return type explicitly (e.g. 'print (float) fabs (3.0)') > Is this feature intended for C or ObjectiveC developers? I'd intend for this to be used by everyone. We specifically added it in response to bug reports from people making heavy use of the system math libraries; as well as from Cocoa (Objective-C) developers making heavy use of functions returning NSRect objects. The reason it's of interest to me in preparing the Objective-C patches is that much of the Objective-C GDB code makes use of being able to pass 'expected_type' arguments to the modified functions, and I'd rather not have to re-architect all those calls before submitting the patches. --Apple-Mail-1--1032422154 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Content-length: 3211 On Saturday, March 9, 2002, at 08:30 PM, Andrew Cagney wrote: I've personally got reservations over introducing a change that, given a file like: void b(void) { double d; d = (double) bar ((float) 3); } radically alters gdb's behavour given: print (double) bar((float) 3) and rejects (?) print bar((float) 3) I think that's a very valid reservation. But let me expand the example a bit: $ cat a.c double foo (float f) { return (f + 1.0); } double bar (float f) { return (f + 1.0); } $ cat b.c double foo (float); int main () { double d1, d2; d1 = (double) foo ((float) 3); d2 = (double) bar ((float) 3); } $ cc -c a.c $ cc -g -c b.c $ cc a.o b.o -o a In "standard" GDB, you get the following results: (gdb) print d1 $1 = 4 (gdb) print d2 $2 = 1 /* generic bogus value */ (gdb) print (double) foo ((float) 3) $3 = 1 /* generic bogus value */ (gdb) print (double) bar ((float) 3) $4 = 1 /* generic bogus value */ In GDB as patched, you get: (gdb) print d1 $1 = 4 (gdb) print d2 $2 = 1074266112 /* generic bogus value */ (gdb) print (double) foo ((float) 3) $3 = 4 (gdb) print (double) bar ((float) 3) $4 = 4 I'd argue that the real problem here is that the calling conventions for a function call are determined for GCC and for GDB in two very different ways. In the case of GCC, it's based on what signature GCC has seen for the function. In the case of GDB, it's based on what debugging information is available for the function being called. This means that it's always going to be possible for there to be a mismatch between behavior of GCC and GDB when evaluating expressions, and my patch does not try to address that. My patch only changes the default behavior from two "incorrect" results (only one of which matches the behavior of GCC), to two "correct" results (only one of which matches the behavior of GCC). I'd argue that it's better to err on the side of returning the correct result, if you have to err at all, and that in the case where you do want the exact behavior of GCC, print (float) (int) bar ((float) 3) is much more intuitive and easy to type than print ((float (*) ()) bar) ((float) 3) 0000,0000,DEDEand rejects (?) print bar((float) 3) Correct; this would print: Unable to call function at 0x1df8: no return type information available. To call this function anyway, you can cast the return type explicitly (e.g. 'print (float) fabs (3.0)') Is this feature intended for C or ObjectiveC developers? I'd intend for this to be used by everyone. We specifically added it in response to bug reports from people making heavy use of the system math libraries; as well as from Cocoa (Objective-C) developers making heavy use of functions returning NSRect objects. The reason it's of interest to me in preparing the Objective-C patches is that much of the Objective-C GDB code makes use of being able to pass 'expected_type' arguments to the modified functions, and I'd rather not have to re-architect all those calls before submitting the patches. --Apple-Mail-1--1032422154--