[Dwarf-Discuss] DWARF attribute for pass return loc in hidden parameter

Yao Qi qiyaoltc@gmail.com
Mon May 7 13:12:27 GMT 2012


On Mon, May 07, 2012 at 08:00:33AM -0400, Ron Brender wrote:
> It has been awhile, but I think what we did on VMS for Itanium was
> 
> 1) If the function declaration has a return type, then (of course)
> there is a returned value.
> 2) If the first formal parameter is artificial (DW_AT_artificial
> present) and has no name (DW_AT_name omitted), then it is interpreted
> as the implicit return parameter (whose location is the important

Isn't it similar to `this' in C++?

> info). Otherwise, the return location is ABI defined.

IIUYC, you suggest that compiler generate debug info for "String
String::substr (int, int)" like this,

 <2><233a>: Abbrev Number: 45 (DW_TAG_subprogram)
    <233b>   DW_AT_external    : 1
    <233c>   DW_AT_name        : (indirect string, offset: 0x1759): substr
    <2340>   DW_AT_decl_file   : 9
    <2341>   DW_AT_decl_line   : 2004
    <2343>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x297d): _ZNKSs6substrEjj
    <2347>   DW_AT_type        : <0x1160>
    <234b>   DW_AT_declaration : 1
    <234c>   DW_AT_sibling     : <0x2361>
 <3><2350>: Abbrev Number: xx (DW_TAG_formal_parameter) // <-- implicit return location 
    <2351>   DW_AT_type        : <0xxxx>
    <2355>   DW_AT_artificial  : 1
 <3><2350>: Abbrev Number: 15 (DW_TAG_formal_parameter) // <-- this
    <2351>   DW_AT_type        : <0x2466>
    <2355>   DW_AT_artificial  : 1
 <3><2356>: Abbrev Number: 16 (DW_TAG_formal_parameter) // <-- 1st int parameter
    <2357>   DW_AT_type        : <0x3b>
 <3><235b>: Abbrev Number: 16 (DW_TAG_formal_parameter) // <-- 2nd int parameter
    <235c>   DW_AT_type        : <0x3b>

In this way, we add one more DW_TAG_formal_parameter for a
DW_TAG_subprogram, which make debug info is not compatible backward.
So it is not very good in practise.  I propose to add a new attribute
DW_AT_return_loc_in_first_implicit_param for a DW_TAG_subprogram, so
that debug info is still compatible backward.  Does it sound good?

> 
> Note, there is no reason to believe that the generated DWARF for a
> given language construct is necessarily the same for every hardware
> architecture.

Oh, absolutely.  The proposed DW_AT_return_loc_in_first_implicit_param
is not language specific nor hardware specific, IMO.


-- 
Yao Qi




More information about the Dwarf-discuss mailing list