From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10429 invoked by alias); 4 May 2012 17:58:51 -0000 Received: (qmail 10415 invoked by uid 22791); 4 May 2012 17:58:50 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO 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; Fri, 04 May 2012 17:58:34 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id A29BB1C6DCA; Fri, 4 May 2012 13:58:33 -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 HHTBuHnVfnPV; Fri, 4 May 2012 13:58:33 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 6F2981C6DC8; Fri, 4 May 2012 13:58:33 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 93821145616; Fri, 4 May 2012 10:58:30 -0700 (PDT) Date: Fri, 04 May 2012 17:58: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: <20120504175830.GQ15555@adacore.com> References: <1334755073-26528-1-git-send-email-yao@codesourcery.com> <20120503011435.GA3294@adacore.com> <4FA22D7B.1040707@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FA22D7B.1040707@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/msg00131.txt.bz2 > 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. I guess that depends, but let's not argue over this. > 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". 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). 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. 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? 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. 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. -- Joel