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

[Doug Evans <dje at google dot com>]

On Mon, Nov 24, 2014 at 12:27 PM, Doug Evans <dje@google.com> wrote:
> 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++"

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.