From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7867 invoked by alias); 7 May 2012 03:39:46 -0000 Received: (qmail 7857 invoked by uid 22791); 7 May 2012 03:39:45 -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; Mon, 07 May 2012 03:39:32 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1SREnJ-0000ZB-Qf from Yao_Qi@mentor.com ; Sun, 06 May 2012 20:39:29 -0700 Received: from SVR-ORW-FEM-02.mgc.mentorg.com ([147.34.96.206]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 6 May 2012 20:39:20 -0700 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.1.289.1; Sun, 6 May 2012 20:39:07 -0700 Message-ID: <4FA743EC.1080903@codesourcery.com> Date: Mon, 07 May 2012 03:39: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> <4FA22D7B.1040707@codesourcery.com> <20120504175830.GQ15555@adacore.com> In-Reply-To: <20120504175830.GQ15555@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/msg00169.txt.bz2 On 05/05/2012 01:58 AM, Joel Brobecker wrote: > I'd like to know what the code is, and what the associated debug info > looks like today. How many parameters would the debug info list for > your function above when the return value is passed as a hidden > parameter? I am guessing 4. I am pretty sure that this is what GNAT > does for Ada (IIRC, GNAT emits a parameter named "TARGET" for it). > It is 3, unfortunately. I got the similar debug info output on both x86 and tic6x: <2><233a>: Abbrev Number: 45 (DW_TAG_subprogram) <233b> DW_AT_external : 1 <233c> DW_AT_name : (indirect string, offset: 0x1759): substr <2340> DW_AT_decl_file : 9 <2341> DW_AT_decl_line : 2004 <2343> DW_AT_MIPS_linkage_name: (indirect string, offset: 0x297d): _ZNKSs6substrEjj <2347> DW_AT_type : <0x1160> <234b> DW_AT_declaration : 1 <234c> DW_AT_sibling : <0x2361> <3><2350>: Abbrev Number: 15 (DW_TAG_formal_parameter) <2351> DW_AT_type : <0x2466> <2355> DW_AT_artificial : 1 <3><2356>: Abbrev Number: 16 (DW_TAG_formal_parameter) <2357> DW_AT_type : <0x3b> <3><235b>: Abbrev Number: 16 (DW_TAG_formal_parameter) <235c> DW_AT_type : <0x3b> > What debug info could do for us is tag that special parameter > using an attribute like DW_AT_return_address_as_implicit_param. > Then we could do have a generic mechanism in GDB that picks it > up, and calls the function appropriately without having to have > insider knowledge as to when such parameter is being used. > Yes, we need some new tag to describe for this situation. > I think there is one avenue that needs to be looked at with > respect to debugging info: Maybe consult with the DWARF committee > to see how this type of situation is supposed to be handled. > Perhaps it's already covered? Yes, it is a good idea to ask in dwarf-discuss@ to see if people there have some smart ideas. Will do. > > Now, I realize that getting the GCC guys to improve the debug > info might not be easily doable. Perhaps a possible option > is to identify the special hidden field using some heuristics > (field name, for instance), and then pretend that this parameter > had the special DWARF attribute. That way, the day GCC starts > describing the implict parameters better, it'll just work out > of the box, and we phase out the hack a few years later. > The heuristics in my mind is to do prologue analysis, to see how many parameters are expected in sub routine, but not sure how reliable and effective it is. > I should add that I am badly overloaded these days and I don't > see it getting better any time soon. It's possible that I am not > getting what the real problem is simply because I don't know C++ > (I learnt the basics over 15 years ago and haven't used it since). > Anyone knowing C++ better should feel free to take the discussion > over. This problem is caused by C++ argument passing in inf-call, but not a C++ problem, IMO. Any one here should be able to comment on this patch, don't be scared by C++ :) -- Yao (齐尧)