Re: dwarf and clones

[Michael Eager <eager at eagercon dot com>]

Reminds me of the song "Send in the Clones".

How is this different from an out-of-line instance?  

It looks like DW_AT_MIPS_clone_origin is the same as DW_AT_abstract_origin.

What would be the effect of describing a clone as a concrete out-of-line
instance?  

DW_AT_MIPS_abstract_name looks like it could be a DW_AT_abstract_origin
with DW_FORM_ref_addr.  This doesn't seem directly related to clones.

David B Anderson wrote:
> 
> >Some highly optimizing compilers (SGI's?) generate multiple copies of a
> >function specialized for particular arguments.  How should such a thing be
> >represented?
> 
> We call them
>         clones
> 
> >The simplest option would be to treat each as a normal function, with
> >almost identical debugging information apart from code addresses.  But it
> >occurs to me that another option would be to treat them as multiple
> >concrete instances of an inline function.
> 
> clones are like concrete out-of-line instances.
> 
> >From the
>         mips_extensions
> document we ship with libdwarf (the usual libdwarf/dwarfdump
> we distribute, see my web page):
> 
> .H 2 "DW_AT_MIPS_clone_origin               0x200a"
> This attribute appears only in a cloned subroutine.
> The procedure is cloned from the same compilation unit.
> The value of this attribute is a reference to
> the original routine in this compilation unit.
> .P
> The 'original' routine means the routine which has all the
> original code.  The cloned routines will always have
> been 'specialized' by IPA.
> A routine with DW_AT_MIPS_clone_origin
> will also have the DW_CC_nocall value of the DW_AT_calling_convention
> attribute.
> 
> .H 2 "DW_AT_MIPS_abstract_name              0x2009"
> This attribute only appears in a DA_TAG_inlined_subroutine DIE.
> The value of this attribute is a string.
> When IPA inlines a routine and the abstract origin is
> in another compilation unit, there is a problem with putting
> in a reference, since the ordering and timing of the
> creation of references is unpredicatable with reference to
> the DIE and compilation unit the reference refers to.
> .P
> Since there may be NO ordering of the compilation units that
> allows a correct reference to be done without some kind of patching,
> and since even getting the information from one place to another
> is a problem, the compiler simply passes the problem on to the debugger.
> .P
> The debugger must match the DW_AT_MIPS_abstract_name
> in the concrete
> inlined instance DIE
> with the  DW_AT_MIPS_abstract_name
> in the abstract inlined subroutine DIE.
> 
> ---------------------------------------------------------
> 
> Again, this is happening when the compiler delays code generation
> to a single final grand step.  Effectively no 'seperate compilation'
> as the seperate compilation steps just generated intermediate code.
> But still sort of separate-compilation as there is no means
> in the dwarf-generation to generate references from one CU to another.
> Thus the DW_AT_MIPS_abstract_name was invented.
> 
> Regards,
> David B. Anderson davea@sgi.com danderson@acm.org http://reality.sgi.com/davea/


-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077