From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23100 invoked by alias); 26 Nov 2014 04:36:49 -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 23090 invoked by uid 89); 26 Nov 2014 04:36:48 -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; Wed, 26 Nov 2014 04:36:47 +0000 Received: by mail-vc0-f171.google.com with SMTP id hy4so935914vcb.16 for ; Tue, 25 Nov 2014 20:36:45 -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=wQOCSMMCETuVWyjBKc+B/NrhJbL7vZa0hpJtx2Gxas0=; b=mNk5B99lxGELWykpEL7q55jUrPmhUbMBgCw3/Kp4zffa6Szk93YBGNQf+4ZLuHUlIh emkOp+qLIe9gZvGc4zReUbfPmQMhwtnoNg5ZAQ1K5YSxWt7pdetqu9RoM6C1NLQqq3U9 mivRJemc3yfJdWuRU6/MjRCrkHaEuHDc8bAaeGpTcZUL9H92V8zboiYbwEB3QGfht3B1 dJf380xodhpUVfugykWlr1m95NkCzJnKWIQ/e2qeCQEE5PHhLbhNwnu6PCxjFoMNbalj j7LsKHjf4gXqP4hKHs/E+cmNUbzaB89/FAPJBxh6D+6H4ork/B1eD89L+1WQ5PfmGknp xhRw== X-Gm-Message-State: ALoCoQmXLZji3mESAUdMwXRLike9XfDk+9QN51jceamKuHdyFq4hqggissdQdVlHfEYJLVTJmuGK MIME-Version: 1.0 X-Received: by 10.52.184.167 with SMTP id ev7mr14172176vdc.67.1416976605001; Tue, 25 Nov 2014 20:36:45 -0800 (PST) Received: by 10.52.114.101 with HTTP; Tue, 25 Nov 2014 20:36:44 -0800 (PST) In-Reply-To: References: Date: Wed, 26 Nov 2014 04:36: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/msg00646.txt.bz2 On Mon, Nov 24, 2014 at 12:27 PM, Doug Evans wrote: > 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++" Hi. While going through this is occurs to me: Do we *need* an assembler testcase here? If we're just testing lambda hand-callability, it would be preferable to just have a .cc test.