From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22254 invoked by alias); 3 May 2012 14:04:44 -0000 Received: (qmail 22240 invoked by uid 22791); 3 May 2012 14:04:43 -0000 X-SWARE-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 May 2012 14:04:30 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SPwdx-0003QJ-7g from ChungLin_Tang@mentor.com ; Thu, 03 May 2012 07:04:29 -0700 Received: from SVR-ORW-FEM-03.mgc.mentorg.com ([147.34.97.39]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 May 2012 07:04:22 -0700 Received: from air.local (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.1.289.1; Thu, 3 May 2012 07:04:28 -0700 Message-ID: <4FA2907A.1020904@codesourcery.com> Date: Thu, 03 May 2012 14:04:00 -0000 From: Chung-Lin Tang User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Joel Brobecker CC: Yao Qi , Subject: Re: [PATCH 1/4] New gdb arch hook: return_with_first_hidden_param_p References: <1334755073-26528-1-git-send-email-yao@codesourcery.com> <20120503011435.GA3294@adacore.com> In-Reply-To: <20120503011435.GA3294@adacore.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit 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: 2012-05/txt/msg00079.txt.bz2 On 12/5/3 9:14 AM, Joel Brobecker wrote: >> 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. It's hard to say whether this should be something fixed in GCC at all, for this just creates yet another C++ ABI version (at least for some architectures) :P > 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. There isn't really anything wrong with how GDB determines this from the type information (the gnu-v3-abi.c code here for C++). The problem is that GCC is inaccurate, making this kind of language-dependent decision impossible in general; it has to be augmented with target-specific information. > 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. Currently, as you can see from the small GCC code excerpt from Yao's first mail, GCC internally abstracts away the details of 'aggregate types', so I'm not sure if there are any language specific considerations here... If convenient, maybe you can try out how the manual call feature for Ada works? i.e. call a function where the aforementioned kind of Ada type is returned, and see how GDB behaves. If SH or C6x is too exotic, hppa and (probably) 32-bit SPARC should also exhibit similarly failing behavior. Thanks, Chung-Lin