Re: [RFC] While processing a struct die, store the method's address in its fn_field

Doug Evans
2014-11-24T20:28:00Z

On Mon, Nov 24, 2014 at 12:22 PM, Doug Evans <dje@google.com> wrote:
> On Mon, Nov 24, 2014 at 7:54 AM, Siva Chandra <sivachandra@google.com> 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 <offset-from-lowpc>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 <sivachandra@google.com>
>>
>> * 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 <sivachandra@google.com>
>>
>> * 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++"