From John.DelSignore@roguewave.com  Mon Sep 15 17:32:31 2014
From: John.DelSignore@roguewave.com (John DelSignore)
Date: Mon, 15 Sep 2014 13:32:31 -0400
Subject: [Dwarf-Discuss] Is this legal DWARF, and if so, what does it mean?
Message-ID: <541722AF.7000306@roguewave.com>

An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20140915/cab99d56/attachment.htm>


From eager@eagercon.com  Mon Sep 15 17:56:09 2014
From: eager@eagercon.com (Michael Eager)
Date: Mon, 15 Sep 2014 10:56:09 -0700
Subject: [Dwarf-Discuss] Is this legal DWARF, and if so,
 what does it mean?
In-Reply-To: <541722AF.7000306@roguewave.com>
References: <541722AF.7000306@roguewave.com>
Message-ID: <54172839.2010206@eagercon.com>

On 09/15/14 10:32, John DelSignore wrote:
> Hi,
>
> TotalView has a customer that has C++ code that produces the following DWARF with the Intel 12.1
> compiler:

ICC generates a lot of idiosyncratic DWARF.

>
>   <0><1192a2>: Abbrev Number: 1 (DW_TAG_compile_unit)
>       DW_AT_comp_dir    : ...SNIPPED...
>       DW_AT_language    : 4    (C++)
>       DW_AT_name        : ...SNIPPED...
>       DW_AT_producer    : Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R)
> 64, Version 12.1 Build 20110811
>   Fixes SameLinkageName MemberPointers
>
>       DW_AT_stmt_list   : 0x5d20
>   <1><119376>: Abbrev Number: 2 (DW_TAG_namespace)
>       DW_AT_name        : std
> ...SNIPPED...
>   <2><268209>: Abbrev Number: 37 (DW_TAG_lexical_block)
>       DW_AT_decl_line   : 1301
>       DW_AT_decl_column : 79
>       DW_AT_decl_file   : 1
>       DW_AT_low_pc      : 0xb02a1
>       DW_AT_high_pc     : 0xb02d4
>   <3><26821e>: Abbrev Number: 38 (DW_TAG_lexical_block)
>       DW_AT_decl_line   : 1351
>       DW_AT_decl_column : 31
>       DW_AT_decl_file   : 1
>       DW_AT_low_pc      : 0xb03a7
>       DW_AT_high_pc     : 0xb03f7
> <2><268234>: Abbrev Number: 16 (DW_TAG_inlined_subroutine)
> ...SNIPPED...
>
> Notice:
>
>  1. The lexical block at <268209> is at "std" namespace scope. What does it mean to have a lexical
>     block at namespace scope? Note that that lexical block contains /only/ another lexical block at
>     <26821e>; no subroutines or variables.

Looks unnecessary to me.  Do you have the source for this file?

I guess this might be generated if you had something like

   namespace std
   {
     {
       {
         /* whatever */
       }
     }
   }

But my guess is that the original source did not look like this.

>  2. The lexical block at <26821e> has an address range that is not nested inside its containing
>     lexical block's address range. Is that legal, and if so, what does that mean? Note that that
>     lexical block contains nothing else; no subroutines, blocks, or variables.

Maybe legal.  The DWARF tree indicates the static nesting.  If a compiler generated
code/data for a nested scope at a different location from the containing scope, then
maybe it might describe the lexical block with a different address range.

Since the lexical block is empty, I'm not sure that this really has any meaning.

ICC does a significant amount of code movement during optimization.  I think
that it doesn't clean up all of the DWARF when it moves code and is accidentally
leaving a now-empty lexical block behind.

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


From ron.brender@gmail.com  Mon Sep 15 18:44:58 2014
From: ron.brender@gmail.com (Ron Brender)
Date: Mon, 15 Sep 2014 14:44:58 -0400
Subject: [Dwarf-Discuss] Is this legal DWARF, and if so,
	what does it mean?
In-Reply-To: <541722AF.7000306@roguewave.com>
References: <541722AF.7000306@roguewave.com>
Message-ID: <CANSbVTgKGRASickrJHaNgKdFCH2hNhggiahjJpMiJDycYdKxdA@mail.gmail.com>

1. I am not enough of an C++ lawyer to comment on the meaning of lexical
blocks inside "std". But I don't recall that the formal definition of "std"
has any such blocks--if not, the presence here is either wrong or the
sloppy remains of some block nested in something else that did not get
properly cleaned up. The lack of anything else inside "std" suggests that
some compilation option may be at play to throttle DWARF production but is
not quite consistently applied.

2. As a DWARF lawyer (which is how I earn my big bucks) I would say that an
address range that is not within its containing block is an error. At best
it suggests poor QOI.

What compilation options produce this? The source being compiled does not
affect "std", of course, but does the compiler produce this same
description of "std" for all sources? The real expert, of course, should be
our very own John Bishop...

My 2 cents...
Ron

On Mon, Sep 15, 2014 at 1:32 PM, John DelSignore <
John.DelSignore at roguewave.com> wrote:

>  Hi,
>
> TotalView has a customer that has C++ code that produces the following
> DWARF with the Intel 12.1 compiler:
>
>  <0><1192a2>: Abbrev Number: 1 (DW_TAG_compile_unit)
>      DW_AT_comp_dir    : ...SNIPPED...
>      DW_AT_language    : 4    (C++)
>      DW_AT_name        : ...SNIPPED...
>      DW_AT_producer    : Intel(R) C++ Intel(R) 64 Compiler XE for
> applications running on Intel(R) 64, Version 12.1 Build 20110811
>  Fixes SameLinkageName MemberPointers
>
>      DW_AT_stmt_list   : 0x5d20
>  <1><119376>: Abbrev Number: 2 (DW_TAG_namespace)
>      DW_AT_name        : std
> ...SNIPPED...
>  <2><268209>: Abbrev Number: 37 (DW_TAG_lexical_block)
>      DW_AT_decl_line   : 1301
>      DW_AT_decl_column : 79
>      DW_AT_decl_file   : 1
>      DW_AT_low_pc      : 0xb02a1
>      DW_AT_high_pc     : 0xb02d4
>  <3><26821e>: Abbrev Number: 38 (DW_TAG_lexical_block)
>      DW_AT_decl_line   : 1351
>      DW_AT_decl_column : 31
>      DW_AT_decl_file   : 1
>      DW_AT_low_pc      : 0xb03a7
>      DW_AT_high_pc     : 0xb03f7
> <2><268234>: Abbrev Number: 16 (DW_TAG_inlined_subroutine)
> ...SNIPPED...
>
> Notice:
>
>    1. The lexical block at <268209> is at "std" namespace scope. What
>    does it mean to have a lexical block at namespace scope? Note that that
>    lexical block contains *only* another lexical block at <26821e>; no
>    subroutines or variables.
>    2. The lexical block at <26821e> has an address range that is not
>    nested inside its containing lexical block's address range. Is that legal,
>    and if so, what does that mean? Note that that lexical block contains
>    nothing else; no subroutines, blocks, or variables.
>
> Thanks, John D.
>
>
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20140915/ec248bf9/attachment.htm>


From John.DelSignore@roguewave.com  Mon Sep 15 19:32:57 2014
From: John.DelSignore@roguewave.com (John DelSignore)
Date: Mon, 15 Sep 2014 15:32:57 -0400
Subject: [Dwarf-Discuss] Is this legal DWARF, and if so,
 what does it mean?
In-Reply-To: <54172839.2010206@eagercon.com>
References: <541722AF.7000306@roguewave.com> <54172839.2010206@eagercon.com>
Message-ID: <54173EE9.9040505@roguewave.com>

Hi Michael,

Thanks for the reply. In-line below...

Michael Eager wrote:
> On 09/15/14 10:32, John DelSignore wrote:
>> Hi,
>>
>> TotalView has a customer that has C++ code that produces the
>> following DWARF with the Intel 12.1
>> compiler:
>
> ICC generates a lot of idiosyncratic DWARF.
I would not disagree with that statement!
>
>>
>>   <0><1192a2>: Abbrev Number: 1 (DW_TAG_compile_unit)
>>       DW_AT_comp_dir    : ...SNIPPED...
>>       DW_AT_language    : 4    (C++)
>>       DW_AT_name        : ...SNIPPED...
>>       DW_AT_producer    : Intel(R) C++ Intel(R) 64 Compiler XE for
>> applications running on Intel(R)
>> 64, Version 12.1 Build 20110811
>>   Fixes SameLinkageName MemberPointers
>>
>>       DW_AT_stmt_list   : 0x5d20
>>   <1><119376>: Abbrev Number: 2 (DW_TAG_namespace)
>>       DW_AT_name        : std
>> ...SNIPPED...
>>   <2><268209>: Abbrev Number: 37 (DW_TAG_lexical_block)
>>       DW_AT_decl_line   : 1301
>>       DW_AT_decl_column : 79
>>       DW_AT_decl_file   : 1
>>       DW_AT_low_pc      : 0xb02a1
>>       DW_AT_high_pc     : 0xb02d4
>>   <3><26821e>: Abbrev Number: 38 (DW_TAG_lexical_block)
>>       DW_AT_decl_line   : 1351
>>       DW_AT_decl_column : 31
>>       DW_AT_decl_file   : 1
>>       DW_AT_low_pc      : 0xb03a7
>>       DW_AT_high_pc     : 0xb03f7
>> <2><268234>: Abbrev Number: 16 (DW_TAG_inlined_subroutine)
>> ...SNIPPED...
>>
>> Notice:
>>
>>  1. The lexical block at <268209> is at "std" namespace scope. What
>> does it mean to have a lexical
>>     block at namespace scope? Note that that lexical block contains
>> /only/ another lexical block at
>>     <26821e>; no subroutines or variables.
>
> Looks unnecessary to me.  Do you have the source for this file?
Unfortunately, I don't. All I have is a shared library that the customer
sent us.
>
> I guess this might be generated if you had something like
>
>   namespace std
>   {
>     {
>       {
>         /* whatever */
>       }
>     }
>   }
>
> But my guess is that the original source did not look like this.
I omitted a bunch of DWARF from my original email, but the DWARF in
question did appear to be inside "namespace std {}", because the names
of the surrounding DIEs were consistent with variables/functions one
would expect to find in "std::", but I don't know that for certain.

Cheers, John D.
>
>>  2. The lexical block at <26821e> has an address range that is not
>> nested inside its containing
>>     lexical block's address range. Is that legal, and if so, what
>> does that mean? Note that that
>>     lexical block contains nothing else; no subroutines, blocks, or
>> variables.
>
> Maybe legal.  The DWARF tree indicates the static nesting.  If a
> compiler generated
> code/data for a nested scope at a different location from the
> containing scope, then
> maybe it might describe the lexical block with a different address range.
>
> Since the lexical block is empty, I'm not sure that this really has
> any meaning.
>
> ICC does a significant amount of code movement during optimization.  I
> think
> that it doesn't clean up all of the DWARF when it moves code and is
> accidentally
> leaving a now-empty lexical block behind.
>


From John.DelSignore@roguewave.com  Mon Sep 15 20:03:46 2014
From: John.DelSignore@roguewave.com (John DelSignore)
Date: Mon, 15 Sep 2014 16:03:46 -0400
Subject: [Dwarf-Discuss] Is this legal DWARF, and if so,
 what does it mean?
In-Reply-To: <CANSbVTgKGRASickrJHaNgKdFCH2hNhggiahjJpMiJDycYdKxdA@mail.gmail.com>
References: <541722AF.7000306@roguewave.com>
	<CANSbVTgKGRASickrJHaNgKdFCH2hNhggiahjJpMiJDycYdKxdA@mail.gmail.com>
Message-ID: <54174622.20703@roguewave.com>

An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20140915/dbd88b84/attachment-0001.htm>


From Paul_Robinson@playstation.sony.com  Tue Sep 16 19:32:52 2014
From: Paul_Robinson@playstation.sony.com (Robinson, Paul)
Date: Tue, 16 Sep 2014 19:32:52 +0000
Subject: [Dwarf-Discuss] DW_AT_default_value reference to "subroutine"
Message-ID: <E3B07FDB86BFF041819DC057DEED8FEA7FA215A0@USCULXMSG03.am.sony.com>

The DW_AT_default_value attribute on a formal_parameter DIE can be used to
express a default argument for the parameter; C++ allows this, for example.
    int foo(int a, int b = 2);
    int bar(int x = foo(3)); // default for x is foo(3,2)
The description of the attribute in DWARF 4 (section 4.1 item 9, p.70)
says it can be a reference to "a variable or subroutine" as well as a
constant. What it means for a variable or constant is pretty obvious; but
it's not really clear about subroutines.  DWARF 4 says it's "the value
returned by the referenced subroutine."

Is this "subroutine" actually a DW_TAG_subprogram DIE?  That's not
expressive enough for the full glory of C++ default arguments.  It's
not even expressive enough to allow the debugger to call a single
arbitrary compiled function, as there's no way to express what
parameters to pass to the compiled function.

Is this "subroutine" actually a DWARF procedure?  That suggests it
should be evaluated like DW_OP_call_ref, which allows executing an
arbitrary DWARF expression, but a DWARF expression can't actually
describe calling a compiled function.

Any old-timers out there who can shed light on the intent of this
terminology?  I see similar verbiage all the way back to DWARF 2.
Thanks,
--paulr



From davea42@earthlink.net  Tue Sep 16 20:32:13 2014
From: davea42@earthlink.net (David Anderson)
Date: Tue, 16 Sep 2014 13:32:13 -0700
Subject: [Dwarf-Discuss] DW_AT_default_value reference to "subroutine"
In-Reply-To: <E3B07FDB86BFF041819DC057DEED8FEA7FA215A0@USCULXMSG03.am.sony.com>
References: <E3B07FDB86BFF041819DC057DEED8FEA7FA215A0@USCULXMSG03.am.sony.com>
Message-ID: <54189E4D.2020509@earthlink.net>

On 09/16/2014 12:32 PM, Robinson, Paul wrote:
> Any old-timers out there who can shed light on the intent of this
> terminology?  I see similar verbiage all the way back to DWARF 2.
> Thanks,


Paul, could you be more specific about where the 'similar verbiage' is?
Thanks.
DavidA.




From ccoutant@gmail.com  Tue Sep 16 20:40:31 2014
From: ccoutant@gmail.com (Cary Coutant)
Date: Tue, 16 Sep 2014 13:40:31 -0700
Subject: [Dwarf-Discuss] DW_AT_default_value reference to "subroutine"
In-Reply-To: <54189E4D.2020509@earthlink.net>
References: <E3B07FDB86BFF041819DC057DEED8FEA7FA215A0@USCULXMSG03.am.sony.com>
	<54189E4D.2020509@earthlink.net>
Message-ID: <CAJimCsFjV=5TQ=2dC7AuhD2y5f7YdYHno4dxEKZObtKJfY10zw@mail.gmail.com>

DWARF v2, Section 4.1:

8. A formal parameter entry describing a formal parameter that has a
default value may have a DW_AT_default_value attribute. The value of
this attribute is a reference to the debugging information entry for a
variable or subroutine. The default value of the parameter is the
value of the variable (which may be constant) or the value returned by
the subroutine. If the value of the DW_AT_default_value attribute is
0, it means that no default value has been specified.

DWARF v3, Section 4.1:

9. A formal parameter entry may have a DW_AT_default_value attribute.
The value of this attribute is a reference to the debugging
information entry for a variable or subroutine, or the value may be a
constant. If it is a reference, the default value of the parameter is
the value of the variable (which may be constant) or the value
returned by the subroutine. If the value of the DW_AT_default_value
attribute is 0, it means that no default value has been specified. If
the value is of form constant, that constant is interpreted as a value
of the type of the formal parameter.

For a constant form there is no way to express the absence of a default value.

DWARF v4, Section 4.1:

9. A DW_AT_default_value attribute for a formal parameter entry. The
value of this attribute is a reference to the debugging information
entry for a variable or subroutine, or the value may be a constant. If
the attribute form is of class reference, the default value of the
parameter is the value of the referenced variable (which may be
constant) or the value returned by the referenced subroutine; a
reference value of 0 means that no default value has been specified.
If the value is of class constant, that constant is interpreted as a
default value of the type of the formal parameter.

For a constant form there is no way to express the absence of a default value.

-cary


On Tue, Sep 16, 2014 at 1:32 PM, David Anderson <davea42 at earthlink.net> wrote:
> On 09/16/2014 12:32 PM, Robinson, Paul wrote:
>> Any old-timers out there who can shed light on the intent of this
>> terminology?  I see similar verbiage all the way back to DWARF 2.
>> Thanks,
>
>
> Paul, could you be more specific about where the 'similar verbiage' is?
> Thanks.
> DavidA.
>
>
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org


From Paul_Robinson@playstation.sony.com  Tue Sep 16 20:50:17 2014
From: Paul_Robinson@playstation.sony.com (Robinson, Paul)
Date: Tue, 16 Sep 2014 20:50:17 +0000
Subject: [Dwarf-Discuss] DW_AT_default_value reference to "subroutine"
In-Reply-To: <54189E4D.2020509@earthlink.net>
References: <E3B07FDB86BFF041819DC057DEED8FEA7FA215A0@USCULXMSG03.am.sony.com>
	<54189E4D.2020509@earthlink.net>
Message-ID: <E3B07FDB86BFF041819DC057DEED8FEA7FA216C8@USCULXMSG03.am.sony.com>

> Paul, could you be more specific about where the 'similar verbiage' is?
> Thanks.
> DavidA.

In DWARF 2, section 4.1 item 8 on p.34.
In DWARF 3, section 4.1 item 9 on p.60.
In DWARF 4, section 4.1 item 9 on p.70.

DWARF 2 did not say the attribute could be a constant; that appeared
in DWARF 3.  Each edition had some editorial massaging that doesn't
affect the semantics; for example the first sentence evolved as follows.

v2: A formal parameter entry describing a formal parameter that has a
    default value may have a DW_AT_default_value attribute.
v3: A formal parameter entry may have a DW_AT_default_value attribute.
v4: A DW_AT_default_value attribute for a formal parameter entry.



From ron.brender@gmail.com  Tue Sep 16 21:07:38 2014
From: ron.brender@gmail.com (Ron Brender)
Date: Tue, 16 Sep 2014 17:07:38 -0400
Subject: [Dwarf-Discuss] DW_AT_default_value reference to "subroutine"
In-Reply-To: <E3B07FDB86BFF041819DC057DEED8FEA7FA215A0@USCULXMSG03.am.sony.com>
References: <E3B07FDB86BFF041819DC057DEED8FEA7FA215A0@USCULXMSG03.am.sony.com>
Message-ID: <CANSbVTgmht5Ar3d+GEFPP7L+MgFeu6Bjezi7Z_G=B9EsNfmRFg@mail.gmail.com>

Looking back through old email and DWARF drafts, I find:

The constant/variable null reference implies no default verbiage existed in
V2 (as others have noted). Al Grant (by way of David Anderson) first raised
the issue of why a reference to an otherwise unnecessary constant should be
needed to handle the simple case of a constant in about Sept 2004. This
eventually became Issue 040909.1 (Matthew Gretton-Dann was the champion).
The allowance of constant forms first shows up in DW3 draft 9.5 in July
2005.

The matter of calling a function was discussed only once that I can find.
One suggestion was to allow a form string to specify text that the debugger
was to evaluate (including making a function call). This achieved no
traction (issues of scope and closures abound). Someone else noted that in
one implementation the compiler creates an anonymous function that just
contains the full call, with arguments as needed. This was thought "too
complicated". And there the matter was dropped.

The summary appears to be: Back in 2005, the reference to subroutine
problem was noted and discussed with no action taken. And here we are nine
years later...

Ron,
Your editor and historian

On Tue, Sep 16, 2014 at 3:32 PM, Robinson, Paul <
Paul_Robinson at playstation.sony.com> wrote:

> The DW_AT_default_value attribute on a formal_parameter DIE can be used to
> express a default argument for the parameter; C++ allows this, for example.
>     int foo(int a, int b = 2);
>     int bar(int x = foo(3)); // default for x is foo(3,2)
> The description of the attribute in DWARF 4 (section 4.1 item 9, p.70)
> says it can be a reference to "a variable or subroutine" as well as a
> constant. What it means for a variable or constant is pretty obvious; but
> it's not really clear about subroutines.  DWARF 4 says it's "the value
> returned by the referenced subroutine."
>
> Is this "subroutine" actually a DW_TAG_subprogram DIE?  That's not
> expressive enough for the full glory of C++ default arguments.  It's
> not even expressive enough to allow the debugger to call a single
> arbitrary compiled function, as there's no way to express what
> parameters to pass to the compiled function.
>
> Is this "subroutine" actually a DWARF procedure?  That suggests it
> should be evaluated like DW_OP_call_ref, which allows executing an
> arbitrary DWARF expression, but a DWARF expression can't actually
> describe calling a compiled function.
>
> Any old-timers out there who can shed light on the intent of this
> terminology?  I see similar verbiage all the way back to DWARF 2.
> Thanks,
> --paulr
>
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20140916/ae35f625/attachment.htm>


From eager@eagerm.com  Tue Sep 16 22:50:51 2014
From: eager@eagerm.com (Michael Eager)
Date: Tue, 16 Sep 2014 15:50:51 -0700
Subject: [Dwarf-Discuss] DW_AT_default_value reference to "subroutine"
In-Reply-To: <E3B07FDB86BFF041819DC057DEED8FEA7FA215A0@USCULXMSG03.am.sony.com>
References: <E3B07FDB86BFF041819DC057DEED8FEA7FA215A0@USCULXMSG03.am.sony.com>
Message-ID: <5418BECB.4050707@eagerm.com>

On 09/16/14 12:32, Robinson, Paul wrote:
> The DW_AT_default_value attribute on a formal_parameter DIE can be used to
> express a default argument for the parameter; C++ allows this, for example.
>      int foo(int a, int b = 2);
>      int bar(int x = foo(3)); // default for x is foo(3,2)
> The description of the attribute in DWARF 4 (section 4.1 item 9, p.70)
> says it can be a reference to "a variable or subroutine" as well as a
> constant. What it means for a variable or constant is pretty obvious; but
> it's not really clear about subroutines.  DWARF 4 says it's "the value
> returned by the referenced subroutine."
>
> Is this "subroutine" actually a DW_TAG_subprogram DIE?  That's not
> expressive enough for the full glory of C++ default arguments.  It's
> not even expressive enough to allow the debugger to call a single
> arbitrary compiled function, as there's no way to express what
> parameters to pass to the compiled function.
>
> Is this "subroutine" actually a DWARF procedure?  That suggests it
> should be evaluated like DW_OP_call_ref, which allows executing an
> arbitrary DWARF expression, but a DWARF expression can't actually
> describe calling a compiled function.
>
> Any old-timers out there who can shed light on the intent of this
> terminology?  I see similar verbiage all the way back to DWARF 2.

See issue 040909.1 (DWARF Version 3):
http://dwarfstd.org/ShowIssue.php?issue=040909.1

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


From davea42@earthlink.net  Wed Sep 17 00:15:56 2014
From: davea42@earthlink.net (David Anderson)
Date: Tue, 16 Sep 2014 17:15:56 -0700
Subject: [Dwarf-Discuss] DW_AT_default_value reference to "subroutine"
In-Reply-To: <E3B07FDB86BFF041819DC057DEED8FEA7FA216C8@USCULXMSG03.am.sony.com>
References: <E3B07FDB86BFF041819DC057DEED8FEA7FA215A0@USCULXMSG03.am.sony.com>
	<54189E4D.2020509@earthlink.net>
	<E3B07FDB86BFF041819DC057DEED8FEA7FA216C8@USCULXMSG03.am.sony.com>
Message-ID: <5418D2BC.3000200@earthlink.net>

On 09/16/2014 01:50 PM, Robinson, Paul wrote:
>> Paul, could you be more specific about where the 'similar verbiage' is?
>> Thanks.
>> DavidA.
> 
> In DWARF 2, section 4.1 item 8 on p.34.
> In DWARF 3, section 4.1 item 9 on p.60.
> In DWARF 4, section 4.1 item 9 on p.70.
> 

My bad. Did not occur to me that you meant across versions,
not within a version.
Thank you Ron B and Mike E for the history!
DavidA.


From Paul_Robinson@playstation.sony.com  Wed Sep 17 21:46:06 2014
From: Paul_Robinson@playstation.sony.com (Robinson, Paul)
Date: Wed, 17 Sep 2014 21:46:06 +0000
Subject: [Dwarf-Discuss] DW_AT_default_value reference to "subroutine"
In-Reply-To: <CANSbVTgmht5Ar3d+GEFPP7L+MgFeu6Bjezi7Z_G=B9EsNfmRFg@mail.gmail.com>
References: <E3B07FDB86BFF041819DC057DEED8FEA7FA215A0@USCULXMSG03.am.sony.com>
	<CANSbVTgmht5Ar3d+GEFPP7L+MgFeu6Bjezi7Z_G=B9EsNfmRFg@mail.gmail.com>
Message-ID: <E3B07FDB86BFF041819DC057DEED8FEA7FA228E8@USCULXMSG03.am.sony.com>

Interestingly, one of the suggestions on the LLVM list was also a string providing the expression for the debugger to evaluate. The C++ standard is well-defined when it comes to how to evaluate the expression, but I can see for the debugger it would be harder.

I'll file an issue to resolve the DW_AT_default_value "subroutine" thing (I've found other related terminology issues so it seemed prudent to file them all together as one issue for everyone to look at).
--paulr

From: Ron Brender [mailto:ron.brender@gmail.com]
Sent: Tuesday, September 16, 2014 2:08 PM
To: Robinson, Paul
Cc: DWARF (dwarf-discuss at lists.dwarfstd.org)
Subject: Re: [Dwarf-Discuss] DW_AT_default_value reference to "subroutine"

Looking back through old email and DWARF drafts, I find:
The constant/variable null reference implies no default verbiage existed in V2 (as others have noted). Al Grant (by way of David Anderson) first raised the issue of why a reference to an otherwise unnecessary constant should be needed to handle the simple case of a constant in about Sept 2004. This eventually became Issue 040909.1 (Matthew Gretton-Dann was the champion). The allowance of constant forms first shows up in DW3 draft 9.5 in July 2005.
The matter of calling a function was discussed only once that I can find. One suggestion was to allow a form string to specify text that the debugger was to evaluate (including making a function call). This achieved no traction (issues of scope and closures abound). Someone else noted that in one implementation the compiler creates an anonymous function that just contains the full call, with arguments as needed. This was thought "too complicated". And there the matter was dropped.
The summary appears to be: Back in 2005, the reference to subroutine problem was noted and discussed with no action taken. And here we are nine years later...
Ron,
Your editor and historian

On Tue, Sep 16, 2014 at 3:32 PM, Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>> wrote:
The DW_AT_default_value attribute on a formal_parameter DIE can be used to
express a default argument for the parameter; C++ allows this, for example.
    int foo(int a, int b = 2);
    int bar(int x = foo(3)); // default for x is foo(3,2)
The description of the attribute in DWARF 4 (section 4.1 item 9, p.70)
says it can be a reference to "a variable or subroutine" as well as a
constant. What it means for a variable or constant is pretty obvious; but
it's not really clear about subroutines.  DWARF 4 says it's "the value
returned by the referenced subroutine."

Is this "subroutine" actually a DW_TAG_subprogram DIE?  That's not
expressive enough for the full glory of C++ default arguments.  It's
not even expressive enough to allow the debugger to call a single
arbitrary compiled function, as there's no way to express what
parameters to pass to the compiled function.

Is this "subroutine" actually a DWARF procedure?  That suggests it
should be evaluated like DW_OP_call_ref, which allows executing an
arbitrary DWARF expression, but a DWARF expression can't actually
describe calling a compiled function.

Any old-timers out there who can shed light on the intent of this
terminology?  I see similar verbiage all the way back to DWARF 2.
Thanks,
--paulr

_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss at lists.dwarfstd.org<mailto:Dwarf-Discuss at lists.dwarfstd.org>
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/attachments/20140917/44e5b549/attachment.htm>


From mjw@redhat.com  Thu Sep 25 15:18:23 2014
From: mjw@redhat.com (Mark Wielaard)
Date: Thu, 25 Sep 2014 17:18:23 +0200
Subject: [Dwarf-Discuss] qualifier modifier type tags vs type signatures
Message-ID: <1411658303.5074.15.camel@bordewijk.wildebeest.org>

Hi,

This came up on the gcc list when extending the number of DWARF type
qualifier modifiers that are handled. But the issue can be shown with
just const and volatile.

The issue is that there is no ordering constraint on the type qualifier
modifier tags (they can appear in any order), but the type signature
computation for type units depends on an flattened ordered DIE tree to
get the same signature for the same type from different compile units.

This seems to only cause a missed opportunity of optimizing when using
type units (the type cannot be merged). But maybe there are more subtle
issues if the same type from different compilation units create
different type unit signatures?

Take for example these two compile units, which both define the same
type struct s, but also have some different types:

1)

int a;
const int b;
volatile const c;

struct s
{
  const volatile int i;
} s;

Here GCC would create a const type that points to an int and a volatile
type that points to that const type. When constructing the DWARF
representation of the struct s, it sees it already has a type DIE for
const volatile int and reuses that. So in this case the DIE chain for
the s.i type comes out as:
DW_TAG_volatile_type -> DW_TAG_const_type -> DW_TAG_base_type

2)

int a;
volatile int b;
volatile const c;

struct s
{
  const volatile int i;
} s;

Here GCC would create a volatile type that points to an int and a const
type that points to that volatile type. When constructing the DWARF
representation of the struct s, it again sees it already has a type DIE
for const volatile int and reuses that. So in this case the DIE chain
for the s.i type comes out as:
DW_TAG_const_type -> DW_TAG_volatile_type -> DW_TAG_base_type

The result is that the flattened description of struct s as used by the
type signature computation is different in these two compile units. And
so the MD5 hash used as signature will differ.

I think what GCC does when constructing the DIE type trees is correct.
It creates the most efficient type tree in both compile units. To create
type trees that look the same in flattened form in both compile units it
would have to add extra type trees (a volatile -> int in one or a const
-> int in the other) that aren't used otherwise. And it cannot really
know which ordering is preferred across all compilation units up front.

But it is somewhat unfortunate that it causes the type units to come out
with different signatures meaning they cannot be merged.

What would be the best way to solve this? I see a couple of options:

0) Don't change anything. It is just a missed optimization.

1) DWARF could prescribe an ordering to use when multiple qualifiers
type tags are in used. This might cause producers to create some extra
type trees if different subsets of type qualifiers are used, but if type
units are used, it might lead to a couple more types to share the same
signature.

2) The Type Signature Computation could be changed to understand that
type qualifier tags pointing to each other need to be sorted first. This
makes the algorithm a little trickier, but means less different type
trees in the compile units.

3) DWARF(v5) could deprecate nested type qualifier modifiers as separate
tags and replace them with one DW_TAG_qualified_type tag with either
separate DW_AT_const|volatile|restrict|atomic flag attributes or a
DW_AT_qualifiers attribute that indicates the combined qualifiers
(const, volatile, restrict, atomic). That removes the whole ordering
issues, so it doesn't matter in which order the DIE chain is flattened.

Ideas and/or opinions?

Thanks,

Mark


From eager@eagerm.com  Thu Sep 25 18:04:35 2014
From: eager@eagerm.com (Michael Eager)
Date: Thu, 25 Sep 2014 11:04:35 -0700
Subject: [Dwarf-Discuss] qualifier modifier type tags vs type signatures
In-Reply-To: <1411658303.5074.15.camel@bordewijk.wildebeest.org>
References: <1411658303.5074.15.camel@bordewijk.wildebeest.org>
Message-ID: <54245933.4060501@eagerm.com>

On 09/25/14 08:18, Mark Wielaard wrote:
> Hi,
>
> This came up on the gcc list when extending the number of DWARF type
> qualifier modifiers that are handled. But the issue can be shown with
> just const and volatile.
>
> The issue is that there is no ordering constraint on the type qualifier
> modifier tags (they can appear in any order), but the type signature
> computation for type units depends on an flattened ordered DIE tree to
> get the same signature for the same type from different compile units.

The C/C++ languages do not place any ordering restrictions on these
qualifiers (or on a number of other qualifiers).

A DWARF producer is free to generate DWARF in any fashion which
accurately describes the source and compilation process.  If you want
to adopt a 'const' before 'volatile' convention (alphabetical) you
are welcome to do so, but there is no requirement to do this.

> This seems to only cause a missed opportunity of optimizing when using
> type units (the type cannot be merged). But maybe there are more subtle
> issues if the same type from different compilation units create
> different type unit signatures?
>
> Take for example these two compile units, which both define the same
> type struct s, but also have some different types:
>
> 1)
>
> int a;
> const int b;
> volatile const c;
>
> struct s
> {
>    const volatile int i;
> } s;
>
> Here GCC would create a const type that points to an int and a volatile
> type that points to that const type. When constructing the DWARF
> representation of the struct s, it sees it already has a type DIE for
> const volatile int and reuses that. So in this case the DIE chain for
> the s.i type comes out as:
> DW_TAG_volatile_type -> DW_TAG_const_type -> DW_TAG_base_type
>
> 2)
>
> int a;
> volatile int b;
> volatile const c;
>
> struct s
> {
>    const volatile int i;
> } s;
>
> Here GCC would create a volatile type that points to an int and a const
> type that points to that volatile type. When constructing the DWARF
> representation of the struct s, it again sees it already has a type DIE
> for const volatile int and reuses that. So in this case the DIE chain
> for the s.i type comes out as:
> DW_TAG_const_type -> DW_TAG_volatile_type -> DW_TAG_base_type
>
> The result is that the flattened description of struct s as used by the
> type signature computation is different in these two compile units. And
> so the MD5 hash used as signature will differ.
>
> I think what GCC does when constructing the DIE type trees is correct.
> It creates the most efficient type tree in both compile units. To create
> type trees that look the same in flattened form in both compile units it
> would have to add extra type trees (a volatile -> int in one or a const
> -> int in the other) that aren't used otherwise. And it cannot really
> know which ordering is preferred across all compilation units up front.

Alternately, GCC could have a set of pre-computed DIE type trees in
preferred order and use a matching equivalent when it generates DWARF.

> But it is somewhat unfortunate that it causes the type units to come out
> with different signatures meaning they cannot be merged.

This seems to be a Quality of Implementation issue.  If a producer
takes a naive approach to generating DWARF type trees, then the results
(in this case, ability to merge debug data) will be worse than if it
takes a more sophisticated approach.

> What would be the best way to solve this? I see a couple of options:
>
> 0) Don't change anything. It is just a missed optimization.

Yes, it's QoI.

> 1) DWARF could prescribe an ordering to use when multiple qualifiers
> type tags are in used. This might cause producers to create some extra
> type trees if different subsets of type qualifiers are used, but if type
> units are used, it might lead to a couple more types to share the same
> signature.

DWARF is descriptive, not prescriptive.

Both DW_TAG_const_type -> DW_TAG_volatile_type -> DW_TAG_base_type and
DW_TAG_volatile_type -> DW_TAG_const_type -> DW_TAG_base_type are valid
descriptions.

That these both describe the same type in C/C++ is a language issue.
Conceivably there might be a language which does not have this same type
equivalence.

> 2) The Type Signature Computation could be changed to understand that
> type qualifier tags pointing to each other need to be sorted first. This
> makes the algorithm a little trickier, but means less different type
> trees in the compile units.

This would mean embedding an understanding of C/C++ type equivalence
into the type signature computation.  DWARF is intended to be language-
neutral, and, in particular, avoid hidden language dependencies.

> 3) DWARF(v5) could deprecate nested type qualifier modifiers as separate
> tags and replace them with one DW_TAG_qualified_type tag with either
> separate DW_AT_const|volatile|restrict|atomic flag attributes or a
> DW_AT_qualifiers attribute that indicates the combined qualifiers
> (const, volatile, restrict, atomic). That removes the whole ordering
> issues, so it doesn't matter in which order the DIE chain is flattened.

The deadline for DWARF Version 5 proposals passed long ago.


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


From John.DelSignore@roguewave.com  Thu Sep 25 18:58:14 2014
From: John.DelSignore@roguewave.com (John DelSignore)
Date: Thu, 25 Sep 2014 14:58:14 -0400
Subject: [Dwarf-Discuss] qualifier modifier type tags vs type signatures
In-Reply-To: <1411658303.5074.15.camel@bordewijk.wildebeest.org>
References: <1411658303.5074.15.camel@bordewijk.wildebeest.org>
Message-ID: <542465C6.7010607@roguewave.com>

Hi Mark,

IMHO, the compiler should be picking a canonical order for the
qualifiers in the DWARF, just like it does for name mangling:

% cat xxx.cxx
void fpcvi(const volatile int*){}
void fpvci(volatile const int*){}
% g++ -g -c xxx.cxx
% nm -C xxx.o
0000000000000000 T fpcvi(int const volatile*)
000000000000000a T fpvci(int const volatile*)
                 U __gxx_personality_v0
% nm xxx.o
0000000000000000 T _Z5fpcviPVKi
000000000000000a T _Z5fpvciPVKi
                 U __gxx_personality_v0
%

The compiler (GCC 4.1.2) canonicalized the qualifier order in the
overload portion of the mangled name to "PVKi", which is "pointer-to
volatile const int". I think the demangler just spit the type out
right-to-left.

Here's the DWARF, with irrelevant lines deleted:

% readelf -wi xxx.o
<1><62>: Abbrev Number: 2 (DW_TAG_subprogram)
     DW_AT_name        : fpcvi
     DW_AT_MIPS_linkage_name: _Z5fpcviPVKi
<2><91>: Abbrev Number: 3 (DW_TAG_formal_parameter)
     DW_AT_type        : <9a>
<1><9a>: Abbrev Number: 4 (DW_TAG_pointer_type)
     DW_AT_type        : <a0>
<1><a0>: Abbrev Number: 5 (DW_TAG_const_type)
     DW_AT_type        : <a5>
<1><a5>: Abbrev Number: 6 (DW_TAG_volatile_type)
     DW_AT_type        : <aa>
<1><aa>: Abbrev Number: 7 (DW_TAG_base_type)
     DW_AT_name        : int
<1><b1>: Abbrev Number: 8 (DW_TAG_subprogram)
     DW_AT_name        : fpvci
     DW_AT_MIPS_linkage_name: _Z5fpvciPVKi
<2><dc>: Abbrev Number: 3 (DW_TAG_formal_parameter)
     DW_AT_type        : <9a>
%

So, in the DWARF, it change the type to "pointer-to const volatile int",
and used the same type for both parameters. It didn't matter what order
I defined the functions, the compiler did the same thing. I think all
this rearranging is perfectly OK.

Given that, your option "0" along seems like the best choice to me. If
someone really wants to squeeze out every last bit of compression, I
think gcc could be changed to canonicalize the order of const/volatile
in your example, and no one would (should) care about the rearrangement
of the qualifiers.

Cheers, John D.

Mark Wielaard wrote:
> Hi,
>
> This came up on the gcc list when extending the number of DWARF type
> qualifier modifiers that are handled. But the issue can be shown with
> just const and volatile.
>
> The issue is that there is no ordering constraint on the type qualifier
> modifier tags (they can appear in any order), but the type signature
> computation for type units depends on an flattened ordered DIE tree to
> get the same signature for the same type from different compile units.
>
> This seems to only cause a missed opportunity of optimizing when using
> type units (the type cannot be merged). But maybe there are more subtle
> issues if the same type from different compilation units create
> different type unit signatures?
>
> Take for example these two compile units, which both define the same
> type struct s, but also have some different types:
>
> 1)
>
> int a;
> const int b;
> volatile const c;
>
> struct s
> {
>   const volatile int i;
> } s;
>
> Here GCC would create a const type that points to an int and a volatile
> type that points to that const type. When constructing the DWARF
> representation of the struct s, it sees it already has a type DIE for
> const volatile int and reuses that. So in this case the DIE chain for
> the s.i type comes out as:
> DW_TAG_volatile_type -> DW_TAG_const_type -> DW_TAG_base_type
>
> 2)
>
> int a;
> volatile int b;
> volatile const c;
>
> struct s
> {
>   const volatile int i;
> } s;
>
> Here GCC would create a volatile type that points to an int and a const
> type that points to that volatile type. When constructing the DWARF
> representation of the struct s, it again sees it already has a type DIE
> for const volatile int and reuses that. So in this case the DIE chain
> for the s.i type comes out as:
> DW_TAG_const_type -> DW_TAG_volatile_type -> DW_TAG_base_type
>
> The result is that the flattened description of struct s as used by the
> type signature computation is different in these two compile units. And
> so the MD5 hash used as signature will differ.
>
> I think what GCC does when constructing the DIE type trees is correct.
> It creates the most efficient type tree in both compile units. To create
> type trees that look the same in flattened form in both compile units it
> would have to add extra type trees (a volatile -> int in one or a const
> -> int in the other) that aren't used otherwise. And it cannot really
> know which ordering is preferred across all compilation units up front.
>
> But it is somewhat unfortunate that it causes the type units to come out
> with different signatures meaning they cannot be merged.
>
> What would be the best way to solve this? I see a couple of options:
>
> 0) Don't change anything. It is just a missed optimization.
>
> 1) DWARF could prescribe an ordering to use when multiple qualifiers
> type tags are in used. This might cause producers to create some extra
> type trees if different subsets of type qualifiers are used, but if type
> units are used, it might lead to a couple more types to share the same
> signature.
>
> 2) The Type Signature Computation could be changed to understand that
> type qualifier tags pointing to each other need to be sorted first. This
> makes the algorithm a little trickier, but means less different type
> trees in the compile units.
>
> 3) DWARF(v5) could deprecate nested type qualifier modifiers as separate
> tags and replace them with one DW_TAG_qualified_type tag with either
> separate DW_AT_const|volatile|restrict|atomic flag attributes or a
> DW_AT_qualifiers attribute that indicates the combined qualifiers
> (const, volatile, restrict, atomic). That removes the whole ordering
> issues, so it doesn't matter in which order the DIE chain is flattened.
>
> Ideas and/or opinions?
>
> Thanks,
>
> Mark
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
>   


From mjw@redhat.com  Fri Sep 26 07:43:46 2014
From: mjw@redhat.com (Mark Wielaard)
Date: Fri, 26 Sep 2014 09:43:46 +0200
Subject: [Dwarf-Discuss] qualifier modifier type tags vs type signatures
In-Reply-To: <54245933.4060501@eagerm.com>
References: <1411658303.5074.15.camel@bordewijk.wildebeest.org>
	<54245933.4060501@eagerm.com>
Message-ID: <1411717426.5074.23.camel@bordewijk.wildebeest.org>

On Thu, 2014-09-25 at 11:04 -0700, Michael Eager wrote:
> On 09/25/14 08:18, Mark Wielaard wrote:
> > This came up on the gcc list when extending the number of DWARF type
> > qualifier modifiers that are handled. But the issue can be shown with
> > just const and volatile.
> >
> > The issue is that there is no ordering constraint on the type qualifier
> > modifier tags (they can appear in any order), but the type signature
> > computation for type units depends on an flattened ordered DIE tree to
> > get the same signature for the same type from different compile units.
> 
> The C/C++ languages do not place any ordering restrictions on these
> qualifiers (or on a number of other qualifiers).
> 
> A DWARF producer is free to generate DWARF in any fashion which
> accurately describes the source and compilation process.  If you want
> to adopt a 'const' before 'volatile' convention (alphabetical) you
> are welcome to do so, but there is no requirement to do this.

Correct. That is indeed the problem. DWARF only has an ordered
representation of the type qualifier concept. That forces producers to
make a choice of ordering even if that doesn't really make sense. On
itself this wouldn't be a problem of course, since the ordering in the
DWARF representation can normally be ignored. But since the order in
representation does matter to other things. Like for the DWARF type
signatures or for tools (like dwz) that work on the language independent
DIE tree representations, the forced ordering cannot really be ignored.

> > I think what GCC does when constructing the DIE type trees is correct.
> > It creates the most efficient type tree in both compile units. To create
> > type trees that look the same in flattened form in both compile units it
> > would have to add extra type trees (a volatile -> int in one or a const
> > -> int in the other) that aren't used otherwise. And it cannot really
> > know which ordering is preferred across all compilation units up front.
> 
> Alternately, GCC could have a set of pre-computed DIE type trees in
> preferred order and use a matching equivalent when it generates DWARF.

Right, but that would not be optimal when you have multiple types with
multiple qualifiers. You'll end up with extra unused type DIE trees in
the compile unit because DWARF forces the producer to choose an ordered
representation. It might be the best we can do though given the current
situation, depending on what optimization you prefer.

> > 1) DWARF could prescribe an ordering to use when multiple qualifiers
> > type tags are in used. This might cause producers to create some extra
> > type trees if different subsets of type qualifiers are used, but if type
> > units are used, it might lead to a couple more types to share the same
> > signature.
> 
> DWARF is descriptive, not prescriptive.
> 
> Both DW_TAG_const_type -> DW_TAG_volatile_type -> DW_TAG_base_type and
> DW_TAG_volatile_type -> DW_TAG_const_type -> DW_TAG_base_type are valid
> descriptions.
> 
> That these both describe the same type in C/C++ is a language issue.
> Conceivably there might be a language which does not have this same type
> equivalence.

Right. So with the current representation of ordered qualifiers we would
need a description whether the DWARF DIE type ordering matters per
language.

> > 2) The Type Signature Computation could be changed to understand that
> > type qualifier tags pointing to each other need to be sorted first. This
> > makes the algorithm a little trickier, but means less different type
> > trees in the compile units.
> 
> This would mean embedding an understanding of C/C++ type equivalence
> into the type signature computation.  DWARF is intended to be language-
> neutral, and, in particular, avoid hidden language dependencies.

Indeed. I don't see how with the current DWARF representation of type
qualifier modifiers we can express the language type equivalence rules
in a way that would avoid having language specific dependencies like
this.

> > 3) DWARF(v5) could deprecate nested type qualifier modifiers as separate
> > tags and replace them with one DW_TAG_qualified_type tag with either
> > separate DW_AT_const|volatile|restrict|atomic flag attributes or a
> > DW_AT_qualifiers attribute that indicates the combined qualifiers
> > (const, volatile, restrict, atomic). That removes the whole ordering
> > issues, so it doesn't matter in which order the DIE chain is flattened.
> 
> The deadline for DWARF Version 5 proposals passed long ago.

Lets table the fix for DWARF.Next then. It is just an issue that came up
now. I don't think it is super urgent to be fixed right away. It has
been this way for years. But eventually it would be nice to make it
possible to express type qualifiers and type equivalence in DWARF in a
cleaner, more language independent way.

Cheers,

Mark


From mjw@redhat.com  Fri Sep 26 08:03:43 2014
From: mjw@redhat.com (Mark Wielaard)
Date: Fri, 26 Sep 2014 10:03:43 +0200
Subject: [Dwarf-Discuss] qualifier modifier type tags vs type signatures
In-Reply-To: <542465C6.7010607@roguewave.com>
References: <1411658303.5074.15.camel@bordewijk.wildebeest.org>
	<542465C6.7010607@roguewave.com>
Message-ID: <1411718623.5074.25.camel@bordewijk.wildebeest.org>

Hi John,

On Thu, 2014-09-25 at 14:58 -0400, John DelSignore wrote:
> IMHO, the compiler should be picking a canonical order for the
> qualifiers in the DWARF, just like it does for name mangling:
> 
> % cat xxx.cxx
> void fpcvi(const volatile int*){}
> void fpvci(volatile const int*){}
> % g++ -g -c xxx.cxx
> % nm -C xxx.o
> 0000000000000000 T fpcvi(int const volatile*)
> 000000000000000a T fpvci(int const volatile*)
>                  U __gxx_personality_v0
> % nm xxx.o
> 0000000000000000 T _Z5fpcviPVKi
> 000000000000000a T _Z5fpvciPVKi
>                  U __gxx_personality_v0
> %
> 
> The compiler (GCC 4.1.2) canonicalized the qualifier order in the
> overload portion of the mangled name to "PVKi", which is "pointer-to
> volatile const int". I think the demangler just spit the type out
> right-to-left.

That is a good suggestion. If the language already has another concept
where the ordering of type qualifiers matters. That way producers can
generate more predictable DWARF. I see this ordering is mandated by the
c++ abi standard:
https://mentorembedded.github.io/cxx-abi/abi.html#mangling-type

Are there standards for other languages that DWARF could refer to when
producers have to turn an order insensitive qualifier set in an ordered
list to express them with DWARF type modifier tags?

> Given that, your option "0" along seems like the best choice to me. If
> someone really wants to squeeze out every last bit of compression, I
> think gcc could be changed to canonicalize the order of const/volatile
> in your example, and no one would (should) care about the rearrangement
> of the qualifiers.

Note that GCC defaults to not use type units at the moment. So it would
be a change to optimize for a slightly different default use case. But
maybe it is time for that. Given that it probably also helps with tools
like dwz. And that the current "smallest possible compile unit"
representation probably doesn't really safe that much normally (it only
matters when the same type is used with different, multiple,
qualifiers). Although I didn't do any measuring.

Ideally though some future DWARF.Next would make it possible to
represent type qualifiers in an order-insensitive way to really make it
language neutral.

Thanks,

Mark


From eager@eagercon.com  Fri Sep 26 15:11:13 2014
From: eager@eagercon.com (Michael Eager)
Date: Fri, 26 Sep 2014 08:11:13 -0700
Subject: [Dwarf-Discuss] qualifier modifier type tags vs type signatures
In-Reply-To: <1411717426.5074.23.camel@bordewijk.wildebeest.org>
References: <1411658303.5074.15.camel@bordewijk.wildebeest.org>	<54245933.4060501@eagerm.com>
	<1411717426.5074.23.camel@bordewijk.wildebeest.org>
Message-ID: <54258211.8010200@eagercon.com>

On 09/26/14 00:43, Mark Wielaard wrote:
> On Thu, 2014-09-25 at 11:04 -0700, Michael Eager wrote:

>> A DWARF producer is free to generate DWARF in any fashion which
>> accurately describes the source and compilation process.  If you want
>> to adopt a 'const' before 'volatile' convention (alphabetical) you
>> are welcome to do so, but there is no requirement to do this.
>
> Correct. That is indeed the problem.

No, this is a design goal of the DWARF standard, not a problem.

 > DWARF only has an ordered
> representation of the type qualifier concept. That forces producers to
> make a choice of ordering even if that doesn't really make sense.

Indeed, the orderings do make sense.  One common use is that they
reflect the source ordering.

What DWARF does not do is impose a design decision which works best for
one producer on all other producers.

> On
> itself this wouldn't be a problem of course, since the ordering in the
> DWARF representation can normally be ignored.

In general, this is not true.
   DW_TAG_const -> DW_TAG_pointer_type -> DW_TAG_base_type
is not the same as
   DW_TAG_pointer_type -> DW_TAG_const -> DW_TAG_base_type

>> Alternately, GCC could have a set of pre-computed DIE type trees in
>> preferred order and use a matching equivalent when it generates DWARF.
>
> Right, but that would not be optimal when you have multiple types with
> multiple qualifiers. You'll end up with extra unused type DIE trees in
> the compile unit because DWARF forces the producer to choose an ordered
> representation. It might be the best we can do though given the current
> situation, depending on what optimization you prefer.

Don't output the ones you don't use.

Optimization is a Quality of Implementation issue.  I'm not advocating any
particular design for GCC or any other producer.  If there are different
ways in which a producer can perform an optimization, then each producer
should be free to pick the one which they use.

> Right. So with the current representation of ordered qualifiers we would
> need a description whether the DWARF DIE type ordering matters per
> language.

DWARF contains DW_AT_LANGUAGE which specifies the language.  Any dependency
that the producer or consumer might have on the specific language should be
handled by interpreting this code.

>>> 2) The Type Signature Computation could be changed to understand that
>>> type qualifier tags pointing to each other need to be sorted first. This
>>> makes the algorithm a little trickier, but means less different type
>>> trees in the compile units.
>>
>> This would mean embedding an understanding of C/C++ type equivalence
>> into the type signature computation.  DWARF is intended to be language-
>> neutral, and, in particular, avoid hidden language dependencies.
>
> Indeed. I don't see how with the current DWARF representation of type
> qualifier modifiers we can express the language type equivalence rules
> in a way that would avoid having language specific dependencies like
> this.

See above.  DWARF does not specify language semantics, whether type
equivalence or any other feature.

DWARF only describes the transformation between source and object.  Anything
which is defined elsewhere, such as language specification, machine description,
OS ABI, and so forth, are described in their respective standards, not in DWARF.

>>> 3) DWARF(v5) could deprecate nested type qualifier modifiers as separate
>>> tags and replace them with one DW_TAG_qualified_type tag with either
>>> separate DW_AT_const|volatile|restrict|atomic flag attributes or a
>>> DW_AT_qualifiers attribute that indicates the combined qualifiers
>>> (const, volatile, restrict, atomic). That removes the whole ordering
>>> issues, so it doesn't matter in which order the DIE chain is flattened.
>>
>> The deadline for DWARF Version 5 proposals passed long ago.
>
> Lets table the fix for DWARF.Next then. It is just an issue that came up
> now. I don't think it is super urgent to be fixed right away. It has
> been this way for years. But eventually it would be nice to make it
> possible to express type qualifiers and type equivalence in DWARF in a
> cleaner, more language independent way.

If there is an argument that DWARF needs to express a language feature,
such as type equivalence, which is internal to the producer and (as far
as I can see) irrelevant to the consumer, then indeed, a language-independent
approach would be appropriate.  So far, you have said that you want
this change to address an internal design issue.

This is QoI issue, not one of DWARF functionality or descriptive ability.
If I can come up with different designs to address your QoI concern in the
time it takes to reply to an email, I can't see that this warrants a change
in the DWARF standard.


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


From eager@eagerm.com  Fri Sep 26 15:11:23 2014
From: eager@eagerm.com (Michael Eager)
Date: Fri, 26 Sep 2014 08:11:23 -0700
Subject: [Dwarf-Discuss] qualifier modifier type tags vs type signatures
In-Reply-To: <1411718623.5074.25.camel@bordewijk.wildebeest.org>
References: <1411658303.5074.15.camel@bordewijk.wildebeest.org>	<542465C6.7010607@roguewave.com>
	<1411718623.5074.25.camel@bordewijk.wildebeest.org>
Message-ID: <5425821B.2040004@eagerm.com>

On 09/26/14 01:03, Mark Wielaard wrote:
> Are there standards for other languages that DWARF could refer to when
> producers have to turn an order insensitive qualifier set in an ordered
> list to express them with DWARF type modifier tags?

DWARF does not reference language standards, since it is intended to be
independent of any particular language.

We could include a list of language standards on our wiki page.

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


From pmachata@redhat.com  Tue Sep 30 23:30:46 2014
From: pmachata@redhat.com (Petr Machata)
Date: Wed, 01 Oct 2014 01:30:46 +0200
Subject: [Dwarf-Discuss] Proposal to reserve .debug_macro opcode 0xff
Message-ID: <m2r3yspty1.fsf@redhat.com>

Hello,

I'm working on support in elfutils for the .debug_macro proposal[1].

The numerical values and semantics of DW_MACINFO_* opcodes are
equivalent to their new-style DW_MACRO_* counterparts.  So a decoder
could transparently read in .debug_macro instead of .debug_macinfo, and
serve the opcodes found there to a client, without fear that they get
misinterpreted.

Were it not for DW_MACINFO_vendor_ext, 0xff.  This value, in new-style
sections, is part of the vendor extension block, as DW_MACRO_hi_user.
It could be allocated and emitted, and a client would misinterpret it as
DW_MACINFO_vendor_ext, decode it, and make decisions based on this
misinterpretation.

I would therefore like to propose that the opcode 0xff is considered
reserved, and DW_MACRO_hi_user is changed to 0xfe.

Does this sound reasonable?  Should I file an issue for this?

[1] http://www.dwarfstd.org/ShowIssue.php?issue=110722.1

Thanks,
Petr


