From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1427 invoked by alias); 21 Feb 2009 12:47:53 -0000 Received: (qmail 1417 invoked by uid 22791); 21 Feb 2009 12:47:53 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 21 Feb 2009 12:47:47 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n1LClYHR008624; Sat, 21 Feb 2009 07:47:34 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n1LClYQF015526; Sat, 21 Feb 2009 07:47:34 -0500 Received: from host0.dyn.jankratochvil.net (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n1LClU5k012002; Sat, 21 Feb 2009 07:47:32 -0500 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.3) with ESMTP id n1LClPxd029692; Sat, 21 Feb 2009 13:47:27 +0100 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.2/Submit) id n1LClP04029688; Sat, 21 Feb 2009 13:47:25 +0100 Date: Sat, 21 Feb 2009 15:58:00 -0000 From: Jan Kratochvil To: Mark Kettenis Cc: drow@false.org, gdb-patches@sourceware.org Subject: Re: [patch] Fix `return' of long/long-long results with no debuginfo Message-ID: <20090221124724.GA28905@host0.dyn.jankratochvil.net> References: <20090211205045.GB9762@caradoc.them.org> <200902112122.n1BLMf8q000100@brahms.sibelius.xs4all.nl> <20090211214646.GA22247@host0.dyn.jankratochvil.net> <200902112244.n1BMiK36012947@brahms.sibelius.xs4all.nl> <20090221000409.GA8771@host0.dyn.jankratochvil.net> <200902211054.n1LAsjYv013808@brahms.sibelius.xs4all.nl> <20090211194511.GA9324@host0.dyn.jankratochvil.net> <200902112040.n1BKdxb3028188@brahms.sibelius.xs4all.nl> <20090211205045.GB9762@caradoc.them.org> <200902112122.n1BLMf8q000100@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902211054.n1LAsjYv013808@brahms.sibelius.xs4all.nl> <200902112122.n1BLMf8q000100@brahms.sibelius.xs4all.nl> User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00411.txt.bz2 On Wed, 11 Feb 2009 22:22:41 +0100, Mark Kettenis wrote: > would it be an idea to use the type of the return value expression given by > the user instead of int as a fallback? > > In the case at hand, "return -1" will still fail, but it would be > possible to do return (void *)-1 to do what the user wanted. It has been proven by the original bugreport even experienced programmers will make a mistake forgetting about the type cast. Therefore GDB "will not work" from the user POV in the most common programming usecase of the `(gdb) return' command: * x86_64 as the current+future primary development architecture. * `void *' (pointer) as the most common return type in modern code. * `(gdb) return 0' to simulate a failed function (`0' because `return NULL' may produce: No symbol "NULL" in current context.) Screenshot of the problem reproducer is at the bottom of this mail. While I do not have such machine at hand (could try UAE - m68k - for caller expecting `long long') I agree with your argument to my former unconditionally `long long'-casting patch: On Wed, 11 Feb 2009 23:44:21 +0100, Mark Kettenis wrote: > I'm not convinced casting to `long long' is safe in all cases, especially on > 32-bit big-endian machines. It really might do the wrong thing there, > exposing garbage or the wrong 32 bits of the 64-bit value. To find a way out of the both requirements this patch implements: > On Sat, 21 Feb 2009 01:04:09 +0100, Jan Kratochvil wrote: > > +/* Set RETURN_VALUE extended to the largest type width which will still be the > > + same value after reading it back using the RETURN_VALUE type. */ So this patch tries as best as it can the original intention of a widest cast but still it verifies it has not broken the compatibility with the type specified by user. Specified either intentionally or unintentionally. It has no regressions. The only imperfection I find is on the big endian 32bit arches one has to use an explicitely cast for callers expecting `long long'. But it cannot be guessed better and big endian arches are minority. Thanks for the review, Jan Reproducer for http://sourceware.org/ml/gdb-patches/2009-02/msg00260.html w/the patch at http://sourceware.org/ml/gdb-patches/2009-02/msg00280.html: cat >/tmp/return.c < #include static void * init (void) { return (void *) (intptr_t) -1; } static void * func (void) { return (void *) 0xdeadf00d00c0ffee; } int main (void) { init (); printf ("%p\n", func ()); return 0; } EOH gcc -o /tmp/return /tmp/return.c -Wall # no -g ./gdb -nx /tmp/return GNU gdb (GDB) 6.8.50.20090220-cvs Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: ... (no debugging symbols found) (gdb) break func Breakpoint 1 at 0x4004dd (gdb) run Starting program: /tmp/return Breakpoint 1, 0x00000000004004dd in func () (gdb) return 0 Make selected stack frame return now? (y or n) y #0 0x00000000004004f7 in main () (gdb) continue Continuing. 0xffffffff00000000 ^^^^^^^^^^^^^^^^^^ -> expected: (nil) Program exited normally.