From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25668 invoked by alias); 9 May 2012 08:39:39 -0000 Received: (qmail 25394 invoked by uid 22791); 9 May 2012 08:39:36 -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; Wed, 09 May 2012 08:39:19 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SS2QW-0001Fy-RT from Yao_Qi@mentor.com ; Wed, 09 May 2012 01:39:16 -0700 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 May 2012 01:39:16 -0700 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.1.289.1; Wed, 9 May 2012 01:39:15 -0700 Message-ID: <4FAA2D25.4060700@codesourcery.com> Date: Wed, 09 May 2012 08:39:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.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> <4FA743EC.1080903@codesourcery.com> <20120507201345.GX15555@adacore.com> In-Reply-To: <20120507201345.GX15555@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/msg00261.txt.bz2 On 05/08/2012 04:13 AM, Joel Brobecker wrote: > 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 ^^^^^^^^^^^ I guess you meant DIE 0x1160 here. > reference type of the other, for instance? Yes, I think so. <2><22b>: Abbrev Number: 10 (DW_TAG_structure_type) <22c> DW_AT_name : (indirect string, offset: 0x17c): basic_string, std::allocator > <230> DW_AT_declaration : 1 <231> DW_AT_sibling : <0x271> <1><1160>: Abbrev Number: 53 (DW_TAG_structure_type) ^^^^^^^ <- function's return type <1161> DW_AT_specification: <0x22b> <1165> DW_AT_byte_size : 4 <1166> DW_AT_decl_file : 7 <1167> DW_AT_decl_line : 52 <1168> DW_AT_sibling : <0x2461> <1><2466>: Abbrev Number: 38 (DW_TAG_pointer_type) ^^^^^^ <- 1st param's type <2467> DW_AT_byte_size : 4 <2468> DW_AT_type : <0x246c> <1><246c>: Abbrev Number: 37 (DW_TAG_const_type) <246d> DW_AT_type : <0x1160> ^^^^^^^^ > 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). Agreed. I stared at these debug info for a while, but unable to have a clue on heuristics. My feeling is that these debug info doesn't give us more than what source code can give, but the heuristics we are looking for are about the difference on different targets, given the same source. That is to say, on different targets, although the number of parameters is different, the debug info is almost the same and hard to get heuristics, >> 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. Yeah, indeed! :) -- Yao (齐尧)