From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18598 invoked by alias); 7 May 2012 20:14:20 -0000 Received: (qmail 18514 invoked by uid 22791); 7 May 2012 20:14:03 -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; Mon, 07 May 2012 20:13:51 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 4CA081C6362; Mon, 7 May 2012 16:13:50 -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 W18wJXaomnnH; Mon, 7 May 2012 16:13:50 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 17ECD1C635E; Mon, 7 May 2012 16:13:49 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 5DFB3145616; Mon, 7 May 2012 13:13:45 -0700 (PDT) Date: Mon, 07 May 2012 20:14: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: <20120507201345.GX15555@adacore.com> References: <1334755073-26528-1-git-send-email-yao@codesourcery.com> <20120503011435.GA3294@adacore.com> <4FA22D7B.1040707@codesourcery.com> <20120504175830.GQ15555@adacore.com> <4FA743EC.1080903@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FA743EC.1080903@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/msg00196.txt.bz2 Hi Yao, > <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 What's the relationship between the first parameter's type (DIE 0x2466) and the function's published returned type (DIE 0x2466)? Is one a reference type of the other, for instance? Basically, what I'm trying to help us find is a heuristic that would be based purely on the DWARF info, rather than on implementation knowledge from the compiler. That way, we can try supporting the current compiler, while at least trying to define what the standard method should be (meaning that you don't need to be the one who coordinates the effort of cleaning that up). > Yes, we need some new tag to describe for this situation. I saw the discussion you started on dwarf-discuss. Thanks! > 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 don't think that's a good idea. Too specialized, and too fragile. And thanks to DWARF frame information, it's something we're slowly getting away from. > 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++ :) I have a better picture of the problem thanks you the copy of the debug info. I agree it's not a C++-specific problem. I was just invinting others to comment as well. I don't want to be too lax and allow a detection method which I think isn't going to scale well. But at the same time, I don't want to be too strict, and discourage you. Having others comment on the issue might bring some ideas we haven't had yet, or correct me on my understanding. -- Joel