From mjw@redhat.com  Wed May  2 11:46:54 2012
From: mjw@redhat.com (Mark Wielaard)
Date: Wed, 02 May 2012 13:46:54 +0200
Subject: [Dwarf-Discuss] DW_AT_entry_pc vs DW_AT_ranges
Message-ID: <1335959214.24235.62.camel@springer.wildebeest.org>

Hi,

I was looking at when GCC produces a DW_AT_entry_pc attribute for a
function DIE that has DW_AT_ranges. It always generates one for a
DW_TAG_inlined_subprogram if the first address in the ranges represents
the first instruction of the original subprogram that is inlined here.

This seems reasonable since in those cases the compiler knows that
address really is the first executable instruction within the range of
addresses as the standard describes. And it allows you to select those
inlined_subprograms that represent all the places where you would want
to put a breakpoint at to catch any "call" of the original subprogram
even when inlined. If only parts of a function is inlined it won't get a
DW_AT_entry_pc and you wouldn't select it.

So two questions about this.

1) Since GCC only emits DW_AT_entry_pc for DW_TAG_subroutine if the
first ranges address corresponds to the instructions of the original
function entry point some consumers now seem to depend on selecting
inlined subprograms that way to pick up all inlined copies that
represent a "call" of the original subprogram. Is there a better way to
express this relationship?

2) That the first DW_AT_ranges address equals the DW_AT_entry_pc address
seems to be a common occurrence. It makes sense the compiler outputs the
ranges in low-to-high address order. But that means the encoding of
DW_AT_entry_pc as a relocatable address is somewhat inefficient. Would
it make sense to add a special form for this situation? Define that
DW_AT_entry_pc can either be of class address or flag. And if it is of
class flag, then when present the address of DW_AT_entry_pc corresponds
to the first address found in DW_AT_ranges.

Thanks,

Mark



From jason@redhat.com  Thu May  3 21:10:34 2012
From: jason@redhat.com (Jason Merrill)
Date: Thu, 03 May 2012 17:10:34 -0400
Subject: [Dwarf-Discuss] C++11 local types as template arguments
Message-ID: <4FA2F44A.9030808@redhat.com>

The C++11 standard allows types with no linkage such as function-local 
classes to be used as template arguments.  This complicates partitioning 
function debug info into a separate compilation unit, as nothing else 
would require a symbolic reference into the function info.  To avoid 
this, I want to leave the type info out of the function unit, but it 
will need a function skeleton to live in for proper scoping.

One solution to this would be to force an abstract/complete split for 
affected functions even if they are not inline.  But not everything in 
the abstract function needs to move out of the function unit; it would 
be nice if I could just move the type to a function declaration in the 
main CU.  I can't seem to find a rule against this, does it seem 
reasonable to other people?

Jason



From qiyaoltc@gmail.com  Mon May  7 04:12:54 2012
From: qiyaoltc@gmail.com (Yao Qi)
Date: Mon, 7 May 2012 12:12:54 +0800
Subject: [Dwarf-Discuss] DWARF attribute for pass return loc in hidden
	parameter
Message-ID: <20120507041252.GA11834@yaolp>

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




From ron.brender@gmail.com  Mon May  7 12:00:33 2012
From: ron.brender@gmail.com (Ron Brender)
Date: Mon, 7 May 2012 08:00:33 -0400
Subject: [Dwarf-Discuss] DWARF attribute for pass return loc in hidden
	parameter
In-Reply-To: <20120507041252.GA11834@yaolp>
References: <20120507041252.GA11834@yaolp>
Message-ID: <CANSbVTgg2CCGC55VX+uOERm_77qnKwajsE2o50R_qsLBu1ZN6w@mail.gmail.com>

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



From qiyaoltc@gmail.com  Mon May  7 13:12:27 2012
From: qiyaoltc@gmail.com (Yao Qi)
Date: Mon, 7 May 2012 21:12:27 +0800
Subject: [Dwarf-Discuss] DWARF attribute for pass return loc in hidden
 parameter
In-Reply-To: <CANSbVTgg2CCGC55VX+uOERm_77qnKwajsE2o50R_qsLBu1ZN6w@mail.gmail.com>
References: <20120507041252.GA11834@yaolp>
	<CANSbVTgg2CCGC55VX+uOERm_77qnKwajsE2o50R_qsLBu1ZN6w@mail.gmail.com>
Message-ID: <20120507131225.GA21616@yaolp>

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



From todd.allen@ccur.com  Mon May  7 15:12:31 2012
From: todd.allen@ccur.com (Todd Allen)
Date: Mon, 7 May 2012 09:12:31 -0600
Subject: [Dwarf-Discuss] DWARF attribute for pass return loc in hidden
 parameter
In-Reply-To: <CANSbVTgg2CCGC55VX+uOERm_77qnKwajsE2o50R_qsLBu1ZN6w@mail.gmail.com>
References: <20120507041252.GA11834@yaolp>
	<CANSbVTgg2CCGC55VX+uOERm_77qnKwajsE2o50R_qsLBu1ZN6w@mail.gmail.com>
Message-ID: <20120507151231.GA27418@toad.ccur.com>

For our Ada 95 compiler, we had a bunch of different kinds of artificial
parameters, some of which we expected our debugger to understand and be able to
construct or interpret.  We added a DW_AT_artificial_type attribute which could
be present anywhere a DW_AT_artificial attribute was found.  Its value was one
of a bunch of enums for each different kind of artificial parameter.  One of
them was DW_ART_return_block, which was a construct used for returning
dynamically-sized objects and related data.  That was a construct specific to
our compiler, but a similar approach could be of use to you if you have control
over what the compiler generates too.

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
> 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
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

-- 
Todd Allen
Concurrent Computer Corporation



From mjw@redhat.com  Tue May 15 18:29:59 2012
From: mjw@redhat.com (Mark Wielaard)
Date: Tue, 15 May 2012 20:29:59 +0200
Subject: [Dwarf-Discuss] DW_AT_entry_pc vs DW_AT_ranges
In-Reply-To: <1335959214.24235.62.camel@springer.wildebeest.org>
References: <1335959214.24235.62.camel@springer.wildebeest.org>
Message-ID: <20120515182958.GA22611@toonder.wildebeest.org>

On Wed, May 02, 2012 at 01:46:54PM +0200, Mark Wielaard wrote:
> I was looking at when GCC produces a DW_AT_entry_pc attribute for a
> function DIE that has DW_AT_ranges. It always generates one for a
> DW_TAG_inlined_subprogram if the first address in the ranges represents
> the first instruction of the original subprogram that is inlined here.
> 
> This seems reasonable since in those cases the compiler knows that
> address really is the first executable instruction within the range of
> addresses as the standard describes. And it allows you to select those
> inlined_subprograms that represent all the places where you would want
> to put a breakpoint at to catch any "call" of the original subprogram
> even when inlined. If only parts of a function is inlined it won't get a
> DW_AT_entry_pc and you wouldn't select it.
> 
> So two questions about this.
> 
> 1) Since GCC only emits DW_AT_entry_pc for DW_TAG_subroutine if the
> first ranges address corresponds to the instructions of the original
> function entry point some consumers now seem to depend on selecting
> inlined subprograms that way to pick up all inlined copies that
> represent a "call" of the original subprogram. Is there a better way to
> express this relationship?
> 
> 2) That the first DW_AT_ranges address equals the DW_AT_entry_pc address
> seems to be a common occurrence. It makes sense the compiler outputs the
> ranges in low-to-high address order. But that means the encoding of
> DW_AT_entry_pc as a relocatable address is somewhat inefficient. Would
> it make sense to add a special form for this situation? Define that
> DW_AT_entry_pc can either be of class address or flag. And if it is of
> class flag, then when present the address of DW_AT_entry_pc corresponds
> to the first address found in DW_AT_ranges.

I got one off-list reply to the second suggestion, adding that having
a constant form could also be added so it is an offset relative to the
first pc of the range.

Does it make sense to write up an proposal for the second part?
I could also hack up a GCC patch for it, to better show the impact
if that would help.

And anybody got an idea on how the more precisely express the
relationship described in the first question?

Thanks,

Mark



