On Tue, Mar 9, 2021 at 11:29 AM Jakub Jelinek <ja...@redhat.com> wrote:
> On Tue, Mar 09, 2021 at 11:16:01AM -0800, David Blaikie via Dwarf-Discuss
> wrote:
> > void f1(int i) { }
> >
> > to include a DW_AT_location with fbreg, nothing about how the ABI
> > represents 'i' - so that would be an ABI gap.
> >
> > In the cases where the compiler does modify any ABI-relevant properties,
> > how would the DWARF consumer know that /that/ location represents the ABI
> > calling convention, but the above fbreg location does not?
> >
> > At least for Clang - the two cases of DAE described below (either
> modifying
> > a parameter to be unused but present (because the signature must be
> > maintained for external callers) and truly removing the parameter (thus
> > shifting other parameters down)) would be indistinguishable in any DWARF
> I
> > can imagine - in both cases the parameter would have no DW_AT_location.
> Any
> > idea how GCC handles that, if it does that kind of optimization?
>
> If GCC optimizes away some parameter (of course that is possible only for
> functions not exported from TUs or on non-exported copies of the exported
> functions), e.g. with
> static __attribute__((noinline)) int foo (int x, int y) { return x; }
> int bar (void) { return foo (3, 17) + foo (3, 18) + foo (3, 19); }
> it will emit:
> .uleb128 0xa # (DIE (0xb9) DW_TAG_formal_parameter)
> .long 0x85 # DW_AT_abstract_origin
> .byte 0x3 # DW_AT_const_value
> for the x case (where the parameter has been optimized away and is known to
> be 3 in all cases) and for y uses a GNU extension (that has been added too
> late in the DWARF5 cycle so it was too late to propose it for DWARF5)
> .uleb128 0x9 # (DIE (0xad) DW_TAG_formal_parameter)
> .long 0x8d # DW_AT_abstract_origin
> .uleb128 0x6 # DW_AT_location
> .byte 0xfa # DW_OP_GNU_parameter_ref
> .long 0x8d
> .byte 0x9f # DW_OP_stack_value
> which has a reference to the formal parameter and value can be (with luck)
> found in DW_TAG_call_site_parameter in the callers.
>
Thanks for the details! So in this case GCC changes the ABI of foo(int x,
int y) to be equivalent to foo(int y) and the parameter description of 'y'
using DW_OP_GNU_parameter_ref says something like "look at where the first
ABI parameter would be stored"? So a DWARF consumer should read the
locations of the parameters - see the constant value of the first parameter
and conclude that the first parameter is omitted from the ABI? Then reading
the second parameter and see that its stored in the ABI first parameter -
and then conclude that since no other parameters are mentioned, only that
first parameter slot is used (to pass the second source parameter)/should
be passed?
Does GCC do anything like the LLVM optimization when the function is
externally visible, but some callers are visible to the optimizer - and the
compiler concludes that since the parameter is unused inside the function
implementation those callers can be modified to pass effectively garbage in
that parameter? And what sort of DWARF does GCC use to describe that?
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
