From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13945 invoked by alias); 3 May 2012 01:15:13 -0000 Received: (qmail 13928 invoked by uid 22791); 3 May 2012 01:15:12 -0000 X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 May 2012 01:14:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 76DCC1C6379; Wed, 2 May 2012 21:14:46 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id T2pkYxipQJhu; Wed, 2 May 2012 21:14:46 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 317191C6377; Wed, 2 May 2012 21:14:45 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 7B921145616; Wed, 2 May 2012 18:14:35 -0700 (PDT) Date: Thu, 03 May 2012 01:15:00 -0000 From: Joel Brobecker To: Yao Qi Cc: gdb-patches@sourceware.org, cltang@codesourcery.com Subject: Re: [PATCH 1/4] New gdb arch hook: return_with_first_hidden_param_p Message-ID: <20120503011435.GA3294@adacore.com> References: <1334755073-26528-1-git-send-email-yao@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1334755073-26528-1-git-send-email-yao@codesourcery.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2012-05/txt/msg00051.txt.bz2 > C++ ABI is intended to be cross-architecture, but C++ ABI ends up being > target-dependent at some points. In practice, GDB has to know which > architecture is special. > > As I said above, GCC changes a language-dependent rule to a > target-dependent rule 'by mistake', so GDB has to be aware of this. That > is the motivation to create this new gdbarch hook. If the hook is not > installed, the default version still complies to existing GDB's behavior, > nothing is changed. I am of two minds about this. If this is a GCC error, then we should also think of the error being fixed in GCC - at least at some point. So, anything we end up doing here should be regarded as a workaround, and I wouldn't want the workaround to start causing problems the day the problem is fixed in GCC. We have the same sort of issue in Ada, where functions returning types whose size is non-static are transformed into procedures where the first parameter is the return value. I haven't had the time to look into this - in particular whether this feature is target- dependent or not. I think we can get away with it by simply inspecting the funtion's parameter name (which is not great). It'd be good if you could show us the debugging information generated for functions that return values vial the first parameter. Ideally, there should be some information about this in the functions debug info. I think that this would be the best way forward - that way, GDB wouldn't have to juggle a number of factors in order to guess which convention to use. In terms of implementation, I think it would be better if we passed the function's symbol as a parameter to the new gdbarch method, rather than the return time. With the symbol, we can determine the language, which might be a useful thing to have when determining how the result is returned. Just a nit, I would name the new method "return_in_hidden_first_param_p" (although, I think we have more general issues to discuss before we can really talk about the code). -- Joel