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

[Doug Evans <dje@google.com>]

On Tue, Nov 25, 2014 at 7:58 PM, Siva Chandra <sivachandra@google.com> wrote:
> I will go over your comments in detail and respond. One clarification
> until then ...
>
> On Tue, Nov 25, 2014 at 7:22 PM, Doug Evans <dje@google.com> wrote:
>> btw, when I try your patch I get one fail:
>>
>> p lambda(10)^M
>> Invalid data type for function to be called.^M
>> (gdb) FAIL: gdb.dwarf2/dw2-member-function-addr.exp: p lambda()
>
> As mentioned in my very first email, the tests depend on
> https://sourceware.org/ml/gdb-patches/2014-11/msg00479.html. We can
> remove this dependency by invoking the operator() explicitly
> "lambda.operator()(10)".

Ah righto.

Digging a bit deeper, I see the lookup_symbol call in value_fn_field
gets passed NULL for block.
That means that lookup_local_symbol won't do anything, but what we're
looking for (as can be seen in the symbol dump) is not in STATIC_BLOCK
(block #001) nor GLOBAL_BLOCK (block #000).

If I manually hack the value passed to lookup_symbol to be a block with
__lambda0::operator()(int) const,
and disable your patch, then "p lambda(5)" works.

So I think we need to figure out how to pass a usable value for block
to lookup_symbol in value_fn_field.  Also, I wouldn't preclude a gcc
bug here and/or a bug in dwarf2read.c where the lambda should have
been in a different block than the one it was put in.