From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32655 invoked by alias); 24 Nov 2014 20:28:00 -0000 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 Received: (qmail 32646 invoked by uid 89); 24 Nov 2014 20:27:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mail-vc0-f171.google.com Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com) (209.85.220.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 24 Nov 2014 20:27:58 +0000 Received: by mail-vc0-f171.google.com with SMTP id hy4so2458405vcb.16 for ; Mon, 24 Nov 2014 12:27:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=F/vMkO4pFKfWpMWeIH2KFwhGifIqY4TD/tXgv3nJXsw=; b=CGl69rsjYer04oqFskg8RHmltY9Cz+CMvEOAD0SZwZVcI7qsZm+aWdSTEbconyxOLO 8+BBblBKFtTnSSeSKVNyeH0NM9Lsa/T7KVb62XMaUVW8g1goyTiB9twzOXI2Xpo8ijYk ficU7q8OIRuWsPusHXjZDk2/ypwdtlwiLl6MlFreo7iW+62jaaRnfSxZNlBd4lweN6lE 5mZJTlcNS6I8sf+S8ySGodSgQzutVS+qjRO+K1LxWbZQypG/p3KMlxaHhvdwk+E0VHve EKOtsUTuze+R9N0xaaI9T2Slk5LJXVmBvGBQXTIAFYrPGVUokgguhhUCVSvwsbno3sfZ 57aw== X-Gm-Message-State: ALoCoQmQtsS9D8Xe2GVnX4Kom+D7WUSXbDCJjCsdnZ3BgLeVf5I2JWDVTrcaSX+uNmOFKZKvH+0r MIME-Version: 1.0 X-Received: by 10.52.111.202 with SMTP id ik10mr11118320vdb.48.1416860876071; Mon, 24 Nov 2014 12:27:56 -0800 (PST) Received: by 10.52.114.101 with HTTP; Mon, 24 Nov 2014 12:27:55 -0800 (PST) In-Reply-To: References: Date: Mon, 24 Nov 2014 20:28:00 -0000 Message-ID: Subject: Re: [RFC] While processing a struct die, store the method's address in its fn_field From: Doug Evans To: Siva Chandra Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00612.txt.bz2 On Mon, Nov 24, 2014 at 12:22 PM, Doug Evans wrote: > On Mon, Nov 24, 2014 at 7:54 AM, Siva Chandra wrote: >> [The tests in this patch depend on this patch: >> https://sourceware.org/ml/gdb-patches/2014-11/msg00479.html. Also, it >> adds a new dwarf2 test which I am not very sure I got it right.] >> >> While processing a struct die, store the method's address in its fn_field. >> >> This enables calling the method when its physname is missing and its >> minsym cannot be discovered, but its address (DW_AT_low_pc) is available. >> For example, this happens for the operator() methods of c++11 lambdas. >> Consider the following C++ code: >> >> int >> main () >> { >> auto lambda = [] (int j) { return j + 113; }; >> return lambda (-113); >> } >> >> When compiled with g++, the DWARF corresponding to the lambda's operator() >> shows up under the DWARF for the function main as follows: >> >> DW_TAG_subprogram >> DW_AT_name "operator()" >> DW_AT_type <0x0000002d> >> DW_AT_artificial yes(1) >> DW_AT_low_pc 0x00400566 >> DW_AT_high_pc 19 >> DW_AT_frame_base len 0x0001: 9c: DW_OP_call_frame_cfa >> DW_AT_object_pointer <0x0000010f> >> DW_AT_GNU_all_call_sites yes(1) >> DW_TAG_pointer_type >> DW_AT_byte_size 0x00000008 >> DW_AT_type <0x000000b9> >> DW_TAG_formal_parameter >> DW_AT_name "__closure" >> DW_AT_type <0x0000011b> >> DW_AT_artificial yes(1) >> DW_AT_location len 0x0002: 9168: DW_OP_fbreg -24 >> DW_TAG_const_type >> DW_AT_type <0x00000109> >> DW_TAG_formal_parameter >> DW_AT_name "j" >> DW_AT_decl_file 0x00000001 >> DW_AT_decl_line 0x00000004 >> DW_AT_type <0x0000002d> >> DW_AT_location len 0x0002: 9164:DW_OP_fbreg -28 >> >> There is no physname and the minsym corresponding to the the operator() >> method does not demangle to its qualified name as specified by the DWARF. >> However, since DW_AT_low_pc is available, it can be used to create a value >> corresponding to the method in value.c:value_fn_field and subsequently be >> passed to call_function_by_hand to invoke it. >> >> gdb/ChangeLog: >> >> 2014-11-24 Siva Chandra Reddy >> >> * dwarf2read.c (dwarf2_add_member_fn): Note the methods address >> if its DT_AT_low_pc is available. >> * gdbtypes.h (struct fn_field): New field ADDR. >> (TYPE_FN_FIELD_ADDR): New macro. >> * value.c (value_fn_field): Use address of the method if >> available. >> >> gdb/testsuite/ChangeLog: >> >> 2014-11-24 Siva Chandra Reddy >> >> * gdb.dwarf2/dw2-member-function-addr.S: New file. >> * gdb.dwarf2/dw2-member-function-addr.exp: New file. > > Hi. > > [I have to admit I hadn't realized gdb used low_pc for the entry point. > Or more likely forgotten. :-) > There's nothing to say that low_pc is the entry point, > but gdb has been using this since forever I'm guessing, > and if it wasn't the entry point presumably the compiler could emit > a DW_TAG_entry_point record.] > > Adding new fields to types or symbols is a big deal. > I'd like to understand why things are failing better. > For normal functions gdb gets the start address > from BLOCK_START (SYMBOL_BLOCK_VALUE (sym)). Bleah, hit Send too soon. Nits: 1) The testcase is amd64-linux specific, which is ok, but the .exp file needs a test to check for this. grep for x86_64 in gdb.dwarf2/*.exp. 2) Please massage the assembler output and change things like this to something more generic. "/tmp" or some such. + .long .LASF3 # DW_AT_comp_dir: "/home/sivachandra/LAB/c++"