Re: [PATCH] Adjustment to DW_TAG_GNU_call_site patch for ICF debug

[Cary Coutant <ccoutant at google dot com>]

> The patch below arranges in that case (as can be seen on the testcase below)
> to have DW_AT_GNU_call_site_target_clobbered (e.g. on x86_64 if this is
> passed in %rdi and OBJ_TYPE_REF token is 0 it is
> DW_OP_breg5 0 DW_OP_deref DW_OP_deref), i.e. where at the call time can be
> the address found. ?The debugger could check that %rdi in this case in the
> called function is the artificial this parameter, assume in C++ it doesn't
> change in the function and use that to discover the called function's
> vtable.
>
> And/or we could invent a new attribute which would contain what the
> .debug_vcall function contained, i.e. the OBJ_TYPE_REF_TOKEN value.

If we can access the pointer to the called function's vtable directly,
I don't think we need the vtable slot index that was stored in the
.debug_vcall table. I'll have to think about it some more, though, to
be sure. How reasonable is it to assume that the artificial this
parameter doesn't move around?

> I haven't seen .debug_dcall/.debug_vcall support patches for gdb anywhere,
> and the patch doesn't disable generation of those sections (though, that
> could be simplified now that the OBJ_TYPE_REF should be available from the
> CALL_INSN).

I started the work in gdb, but dropped it a while back and haven't
gotten back to it. There's no legacy yet that depends on those two
tables.

-cary