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

[Ron Brender]

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
info). Otherwise, the return location is ABI defined.

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

Does that help, or am I missing the point?

Ron

-------------------------------------------------------------------------------------------
On Mon, May 7, 2012 at 12:12 AM, Yao Qi <qiyaoltc at gmail.com> wrote:
> Hi,
>
> We encounter a problem in GDB that we are unable to determine the
> number of parameters a certain function is needed, if the function is
> a c++ function, and returns value of object. ?(See
> http://sourceware.org/ml/gdb-patches/2012-05/msg00169.html)
> I'd like to know if DWARF has such attribute to help debugger to
> understand about the implicit parameter of a certain function.
>
> In GDB, when we do a "inferior call", call a function in debuggee from
> debugger, GDB has to know the parameters of target function, and pass
> the right parameters in the right place, usually specified by ABI.
> When we do this in GDB, (s is a String object)
>
> ?(gdb) print (const char *) (s=s.substr(0,4))
>
> GDB has to pass all parameters to `substr', but the problem is
> `substr' needs different number of parameters on different arch. ?On
> x86, `substr' expects to see four parameters, "return location",
> "this", "0", and "4", it complies to C++ ABI, however, on some other
> targets, such as tic6x,SH,m68k, etc, `substr' expects three
> parameters, "this", "0", and "4". ?For the debug information, debugger
> is unable to know the difference, as below,
>
> ?<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: 15 (DW_TAG_formal_parameter)
> ? ?<2351> ? DW_AT_type ? ? ? ?: <0x2466>
> ? ?<2355> ? DW_AT_artificial ?: 1
> ?<3><2356>: Abbrev Number: 16 (DW_TAG_formal_parameter)
> ? ?<2357> ? DW_AT_type ? ? ? ?: <0x3b>
> ?<3><235b>: Abbrev Number: 16 (DW_TAG_formal_parameter)
> ? ?<235c> ? DW_AT_type ? ? ? ?: <0x3b>
>
> DWARF has DW_TAG_formal_parameter to describe the parameter for a
> certain function, but looks the "return location in the first implicit
> parameter" is not covered by DWARF so far, unless I miss something
> here. ?I am wondering that we may add a new
> DW_AT_return_loc_in_first_implicit_param to DW_TAG_subprogram, so that
> debugger can pass correct parameters to them. ?Thoughts?
>
> --
> Yao Qi
>
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org