Re: dwarf and clones

[David B Anderson <davea at quasar dot engr dot sgi dot com>]

>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/