From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15229 invoked by alias); 3 May 2012 07:00:24 -0000 Received: (qmail 15197 invoked by uid 22791); 3 May 2012 07:00:20 -0000 X-SWARE-Spam-Status: No, hits=-4.2 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 07:00:05 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SPq1D-0004Er-Oq from Yao_Qi@mentor.com ; Thu, 03 May 2012 00:00:03 -0700 Received: from SVR-ORW-FEM-05.mgc.mentorg.com ([147.34.97.43]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 May 2012 00:00:03 -0700 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.1.289.1; Thu, 3 May 2012 00:00:02 -0700 Message-ID: <4FA22D7B.1040707@codesourcery.com> Date: Thu, 03 May 2012 07:00:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120412 Thunderbird/11.0.1 MIME-Version: 1.0 To: Joel Brobecker CC: , 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="UTF-8" Content-Transfer-Encoding: 8bit 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/msg00058.txt.bz2 On 05/03/2012 09:14 AM, Joel Brobecker wrote: > 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. > Joel, thanks for the review. I am not sure we can call this an "error" in GCC, especially it is used for some years. The ABI of different arch may overwrite some rules in general ABI, like tic6x in this case. > 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. I don't know how debug info helps here. In fact, the patch is more about "argument passing" rather than "value return". On some arch, function "s.substr(0,4)" expects three parameters "this", "0", and "4", while other some other arch, it expects four, "return location", "this", "0", and "4". However, GDB pass four parameters unconditionally, which causes trouble. The debug information (.debug_frame is most relevant in this case I guess) is about in a certain function, which registers are stored in which place. So debug infor can't tell how registers are used to pass parameters during a function call, which should be covered by "calling convention", usually part of ABI. > > 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). The new hook name might be renamed to 'pass_return_loc_in_first_hidden_param_p'. -- Yao (齐尧)