From eager@eagerm.com  Wed Oct  1 00:06:12 2014
From: eager@eagerm.com (Michael Eager)
Date: Tue, 30 Sep 2014 17:06:12 -0700
Subject: [Dwarf-Discuss] Proposal to reserve .debug_macro opcode 0xff
In-Reply-To: <m2r3yspty1.fsf@redhat.com>
References: <m2r3yspty1.fsf@redhat.com>
Message-ID: <542B4574.20307@eagerm.com>

On 09/30/14 16:30, Petr Machata wrote:
> 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
>

Yes, please file a comment.


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


From jakub@redhat.com  Wed Oct  1 05:17:34 2014
From: jakub@redhat.com (Jakub Jelinek)
Date: Wed, 1 Oct 2014 07:17:34 +0200
Subject: [Dwarf-Discuss] Proposal to reserve .debug_macro opcode 0xff
In-Reply-To: <m2r3yspty1.fsf@redhat.com>
References: <m2r3yspty1.fsf@redhat.com>
Message-ID: <20141001051734.GL1986@tucnak.redhat.com>

On Wed, Oct 01, 2014 at 01:30:46AM +0200, Petr Machata wrote:
> 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

All of values from DW_MACRO_lo_user to DW_MACRO_hi_user are meant for
vendor extensions and can have arbitrary arguments, I doubt
the particular one (with an integer and inline string argument)
is useful for anything.  If a vendor needs an extension with a string
argument, it is much better to either encode the constant in the
DW_MACRO_lo_user + constant opcode and just use DW_FORM_strp (not
DW_FORM_string) argument, or use DW_FORM_udate, DW_FORM_strp
arguments.  For DW_MACRO_{lo,hi}_user values you need to handle
them specially, not pass them through, any case, because you need
to read the description of their arguments and print them likely
as DW_MACRO_lo_user+%02x or similar.

	Jakub


From pmachata@redhat.com  Wed Oct  1 15:36:23 2014
From: pmachata@redhat.com (Petr Machata)
Date: Wed, 01 Oct 2014 17:36:23 +0200
Subject: [Dwarf-Discuss] Proposal to reserve .debug_macro opcode 0xff
In-Reply-To: <20141001051734.GL1986@tucnak.redhat.com> (Jakub Jelinek's
	message of "Wed, 1 Oct 2014 07:17:34 +0200")
References: <m2r3yspty1.fsf@redhat.com>
	<20141001051734.GL1986@tucnak.redhat.com>
Message-ID: <m2mw9fpzt4.fsf@redhat.com>

Jakub Jelinek <jakub at redhat.com> writes:

> All of values from DW_MACRO_lo_user to DW_MACRO_hi_user are meant for
> vendor extensions and can have arbitrary arguments, I doubt
> the particular one (with an integer and inline string argument)
> is useful for anything.  If a vendor needs an extension with a string
> argument, it is much better to either encode the constant in the
> DW_MACRO_lo_user + constant opcode and just use DW_FORM_strp (not
> DW_FORM_string) argument, or use DW_FORM_udate, DW_FORM_strp

So the problem that I'm talking about is this: imagine there's a bunch
of DW_MACINFO_vendor_ext extensions somewhere in the wild.  The vendor
would naturally map those to the new-style section, each extension would
get it's own DW_MACRO_FOO_* opcode, and eventually DW_MACRO_hi_user gets
allocated as well (as DW_MACRO_FOO_frobnicate, and it just happens to
have a numeric and a string parameter).

At this point, 0xff double-serves as either DW_MACINFO_vendor_ext (in
which case the first parameter is vendor opcode and the second is
whatever), or DW_MACRO_FOO_frobnicate (in which case the first parameter
is, say, frobnicator salt and second is whatever).

For this reason a library that decodes .debug_macinfo can't simply
transparently switch to .debug_macro, because some client might
misinterpret 0xff as DW_MACINFO_vendor_ext, even if what we mean is
DW_MACRO_FOO_frobnicate.  The client could use other means to
disambiguate the situation, but a .debug_macinfo client wouldn't know
it's supposed to.

This is the only opcode with this problem.  Others would be handled by
whatever means the client has for handling unsupported opcodes, most
likely by bailing out or ignoring them.

> arguments.  For DW_MACRO_{lo,hi}_user values you need to handle
> them specially, not pass them through, any case, because you need
> to read the description of their arguments and print them likely
> as DW_MACRO_lo_user+%02x or similar.

There's not much difference actually.

E.g. take DW_MACRO_define.  The standard doesn't mention what form its
first argument should have (should I open another issue for this?).  We
"know" it's DW_FORM_udata, because "that's how it has always been" (plus
it makes sense), but if that opcode is not described in the prototype
table, I formally don't know how to decode it.

Now if the table does mention that opcode, what if, instead of
DW_FORM_string for its second argument, it uses DW_FORM_strp?  Or if it
adds a third argument?  I mean, why not?  What's the harm?  It makes no
sense, but per my reading, it is valid.  And I'd better use that
information when decoding the section, otherwise garbage comes out.  And
if the extra arguments can be safely ignored by the client, that's not
even a problem.

So parsing and serving vendor extensions is largely not different from
parsing and serving standard opcodes.

What a client does with what I serve is their problem.  If we are
talking about a readelf-like application, then showing the overlapping
part of DW_MACRO_* as DW_MACINFO_* is no problem at all, as the
semantics are the same.  Unless we talk about 0xff, which would throw
this client off, because what 0xff means in DW_MACRO_* world is
extremely likely not what it means in DW_MACINFO_* world.

Similarly a client that knows about DW_MACRO_* can just interpret all
DW_MACINFO_* opcodes as DW_MACRO_* ones and not be worried that it puts
anyone into great confusion.  Except for 0xff.


None of this is technical problem.  We can add new interfaces, add
version-querying, etc., that's all fine.  But reserving 0xff would allow
us to keep existing interfaces instead of having to invent new ones to
protect extant clients.

Thanks,
Petr


From daniel.gutson@tallertechnologies.com  Sun Oct  5 14:27:26 2014
From: daniel.gutson@tallertechnologies.com (Daniel Gutson)
Date: Sun, 5 Oct 2014 11:27:26 -0300
Subject: [Dwarf-Discuss] Question / Proposal: breakpoints at global C++
	constructors and destructors
Message-ID: <CAF5HaEX-KANcS+t_B-xdrpVqZHPwrATN=zdCO32c0tBkcri6Bw@mail.gmail.com>

Hello,

   this is my first post to this list.

Context: I've been a gdb and gcc maintainer in the past, but I'm not a
DWARF expert, so my post is
from the user's POV.

PROBLEM: ability to break in (all) the global objects' constructors
(that is, before main() is called),
and destructors (after main() ).

As a matter of proof of concept, we've developed a gdb script that is
also nontrivial and imperfect.
FWIW, there were two ways: one implementation-agnostic by regex
finding the ctors of all objects and
adding breakpoints in all of them, then breaking at main, disabling
the former and continuing;
another way was implementation-specific, knowing the internals of the
__static_initialization_and_destruction_0
mechanism. Our proof of concept used the first approach but had a lot of issues.

So, it would be absolutely trivial if there was a DW_CTOR_CALL /
DW_DTOR_CALL with the address
of the call instruction, so the debugger can break on those calls, and
do a step-into to get into the ctor/dtor body.

Feedback?

Thanks!

   Daniel.


-- 

Daniel F. Gutson
Chief Engineering Officer, SPD


San Lorenzo 47, 3rd Floor, Office 5

C?rdoba, Argentina


Phone: +54 351 4217888 / +54 351 4218211

Skype: dgutson


From eager@eagercon.com  Sun Oct  5 15:47:50 2014
From: eager@eagercon.com (Michael Eager)
Date: Sun, 05 Oct 2014 08:47:50 -0700
Subject: [Dwarf-Discuss] Question / Proposal: breakpoints at global C++
 constructors and destructors
In-Reply-To: <CAF5HaEX-KANcS+t_B-xdrpVqZHPwrATN=zdCO32c0tBkcri6Bw@mail.gmail.com>
References: <CAF5HaEX-KANcS+t_B-xdrpVqZHPwrATN=zdCO32c0tBkcri6Bw@mail.gmail.com>
Message-ID: <54316826.3080808@eagercon.com>

On 10/05/14 07:27, Daniel Gutson wrote:
> Hello,
>
>     this is my first post to this list.
>
> Context: I've been a gdb and gcc maintainer in the past, but I'm not a
> DWARF expert, so my post is
> from the user's POV.
>
> PROBLEM: ability to break in (all) the global objects' constructors
> (that is, before main() is called),
> and destructors (after main() ).
>
> As a matter of proof of concept, we've developed a gdb script that is
> also nontrivial and imperfect.
> FWIW, there were two ways: one implementation-agnostic by regex
> finding the ctors of all objects and
> adding breakpoints in all of them, then breaking at main, disabling
> the former and continuing;
> another way was implementation-specific, knowing the internals of the
> __static_initialization_and_destruction_0
> mechanism. Our proof of concept used the first approach but had a lot of issues.
>
> So, it would be absolutely trivial if there was a DW_CTOR_CALL /
> DW_DTOR_CALL with the address
> of the call instruction, so the debugger can break on those calls, and
> do a step-into to get into the ctor/dtor body.

I don't think that a special DWARF TAG would be required for this.
You could use DW_TAG_subprogram to describe the ctor/dtor routine,
marked with with DW_AT_artificial.


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


From daniel.gutson@tallertechnologies.com  Sun Oct  5 15:57:13 2014
From: daniel.gutson@tallertechnologies.com (Daniel Gutson)
Date: Sun, 5 Oct 2014 12:57:13 -0300
Subject: [Dwarf-Discuss] Question / Proposal: breakpoints at global C++
 constructors and destructors
In-Reply-To: <54316826.3080808@eagercon.com>
References: <CAF5HaEX-KANcS+t_B-xdrpVqZHPwrATN=zdCO32c0tBkcri6Bw@mail.gmail.com>
	<54316826.3080808@eagercon.com>
Message-ID: <CAF5HaEU_KPsZYQaRUzMtNwS-BSjY5Kwyit_aZxSwXfRnN-A3+g@mail.gmail.com>

On Sun, Oct 5, 2014 at 12:47 PM, Michael Eager <eager at eagercon.com> wrote:
> On 10/05/14 07:27, Daniel Gutson wrote:
>>
>> Hello,
>>
>>     this is my first post to this list.
>>
>> Context: I've been a gdb and gcc maintainer in the past, but I'm not a
>> DWARF expert, so my post is
>> from the user's POV.
>>
>> PROBLEM: ability to break in (all) the global objects' constructors
>> (that is, before main() is called),
>> and destructors (after main() ).
>>
>> As a matter of proof of concept, we've developed a gdb script that is
>> also nontrivial and imperfect.
>> FWIW, there were two ways: one implementation-agnostic by regex
>> finding the ctors of all objects and
>> adding breakpoints in all of them, then breaking at main, disabling
>> the former and continuing;
>> another way was implementation-specific, knowing the internals of the
>> __static_initialization_and_destruction_0
>> mechanism. Our proof of concept used the first approach but had a lot of
>> issues.
>>
>> So, it would be absolutely trivial if there was a DW_CTOR_CALL /
>> DW_DTOR_CALL with the address
>> of the call instruction, so the debugger can break on those calls, and
>> do a step-into to get into the ctor/dtor body.
>
>
> I don't think that a special DWARF TAG would be required for this.
> You could use DW_TAG_subprogram to describe the ctor/dtor routine,
> marked with with DW_AT_artificial.

It's not a solution, because the problem is not identifying the
function (the constructor
in this case), but the CALL to the constructor.
Why? Because the same class could have several global instances, and non-global
(attributes, local) instances.
So what is needed is to identify the invoking places.

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



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD


San Lorenzo 47, 3rd Floor, Office 5

C?rdoba, Argentina


Phone: +54 351 4217888 / +54 351 4218211

Skype: dgutson


From eager@eagercon.com  Sun Oct  5 16:07:30 2014
From: eager@eagercon.com (Michael Eager)
Date: Sun, 05 Oct 2014 09:07:30 -0700
Subject: [Dwarf-Discuss] Question / Proposal: breakpoints at global C++
 constructors and destructors
In-Reply-To: <CAF5HaEU_KPsZYQaRUzMtNwS-BSjY5Kwyit_aZxSwXfRnN-A3+g@mail.gmail.com>
References: <CAF5HaEX-KANcS+t_B-xdrpVqZHPwrATN=zdCO32c0tBkcri6Bw@mail.gmail.com>	<54316826.3080808@eagercon.com>
	<CAF5HaEU_KPsZYQaRUzMtNwS-BSjY5Kwyit_aZxSwXfRnN-A3+g@mail.gmail.com>
Message-ID: <54316CC2.2090209@eagercon.com>

On 10/05/14 08:57, Daniel Gutson wrote:
> On Sun, Oct 5, 2014 at 12:47 PM, Michael Eager <eager at eagercon.com> wrote:
>> On 10/05/14 07:27, Daniel Gutson wrote:
>>>
>>> Hello,
>>>
>>>      this is my first post to this list.
>>>
>>> Context: I've been a gdb and gcc maintainer in the past, but I'm not a
>>> DWARF expert, so my post is
>>> from the user's POV.
>>>
>>> PROBLEM: ability to break in (all) the global objects' constructors
>>> (that is, before main() is called),
>>> and destructors (after main() ).
>>>
>>> As a matter of proof of concept, we've developed a gdb script that is
>>> also nontrivial and imperfect.
>>> FWIW, there were two ways: one implementation-agnostic by regex
>>> finding the ctors of all objects and
>>> adding breakpoints in all of them, then breaking at main, disabling
>>> the former and continuing;
>>> another way was implementation-specific, knowing the internals of the
>>> __static_initialization_and_destruction_0
>>> mechanism. Our proof of concept used the first approach but had a lot of
>>> issues.
>>>
>>> So, it would be absolutely trivial if there was a DW_CTOR_CALL /
>>> DW_DTOR_CALL with the address
>>> of the call instruction, so the debugger can break on those calls, and
>>> do a step-into to get into the ctor/dtor body.
>>
>>
>> I don't think that a special DWARF TAG would be required for this.
>> You could use DW_TAG_subprogram to describe the ctor/dtor routine,
>> marked with with DW_AT_artificial.
>
> It's not a solution, because the problem is not identifying the
> function (the constructor
> in this case), but the CALL to the constructor.
> Why? Because the same class could have several global instances, and non-global
> (attributes, local) instances.
> So what is needed is to identify the invoking places.

If what you want to do is break at all constructors/destructors, I
don't see why you need to break at the calling site.

Can you give an example?

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


From daniel.gutson@tallertechnologies.com  Sun Oct  5 16:24:35 2014
From: daniel.gutson@tallertechnologies.com (Daniel Gutson)
Date: Sun, 5 Oct 2014 13:24:35 -0300
Subject: [Dwarf-Discuss] Question / Proposal: breakpoints at global C++
 constructors and destructors
In-Reply-To: <54316CC2.2090209@eagercon.com>
References: <CAF5HaEX-KANcS+t_B-xdrpVqZHPwrATN=zdCO32c0tBkcri6Bw@mail.gmail.com>
	<54316826.3080808@eagercon.com>
	<CAF5HaEU_KPsZYQaRUzMtNwS-BSjY5Kwyit_aZxSwXfRnN-A3+g@mail.gmail.com>
	<54316CC2.2090209@eagercon.com>
Message-ID: <CAF5HaEVK7JhY2axpjDwTGLfEDriCfP5G3dD49JWVLnoMpJ82nQ@mail.gmail.com>

On Sun, Oct 5, 2014 at 1:07 PM, Michael Eager <eager at eagercon.com> wrote:
> On 10/05/14 08:57, Daniel Gutson wrote:
>>
>> On Sun, Oct 5, 2014 at 12:47 PM, Michael Eager <eager at eagercon.com> wrote:
>>>
>>> On 10/05/14 07:27, Daniel Gutson wrote:
>>>>
>>>>
>>>> Hello,
>>>>
>>>>      this is my first post to this list.
>>>>
>>>> Context: I've been a gdb and gcc maintainer in the past, but I'm not a
>>>> DWARF expert, so my post is
>>>> from the user's POV.
>>>>
>>>> PROBLEM: ability to break in (all) the global objects' constructors
>>>> (that is, before main() is called),
>>>> and destructors (after main() ).
>>>>
>>>> As a matter of proof of concept, we've developed a gdb script that is
>>>> also nontrivial and imperfect.
>>>> FWIW, there were two ways: one implementation-agnostic by regex
>>>> finding the ctors of all objects and
>>>> adding breakpoints in all of them, then breaking at main, disabling
>>>> the former and continuing;
>>>> another way was implementation-specific, knowing the internals of the
>>>> __static_initialization_and_destruction_0
>>>> mechanism. Our proof of concept used the first approach but had a lot of
>>>> issues.
>>>>
>>>> So, it would be absolutely trivial if there was a DW_CTOR_CALL /
>>>> DW_DTOR_CALL with the address
>>>> of the call instruction, so the debugger can break on those calls, and
>>>> do a step-into to get into the ctor/dtor body.
>>>
>>>
>>>
>>> I don't think that a special DWARF TAG would be required for this.
>>> You could use DW_TAG_subprogram to describe the ctor/dtor routine,
>>> marked with with DW_AT_artificial.
>>
>>
>> It's not a solution, because the problem is not identifying the
>> function (the constructor
>> in this case), but the CALL to the constructor.
>> Why? Because the same class could have several global instances, and
>> non-global
>> (attributes, local) instances.
>> So what is needed is to identify the invoking places.
>
>
> If what you want to do is break at all constructors/destructors, I

No, not *all*, only for those instances which ar grlobal

> don't see why you need to break at the calling site.

because otherwise I would break in all non-global instances' construction too.

>
> Can you give an example?

OK:

struct Base
{
    Base(int) {}
};

struct Der: Base
{
    Der(int x) : Base(x) {}
};

Base b1; // break here
Der d1;   // break at d1's ctor body, not during Der::Base construction

int main()
{
   Base b2;  // don't break here
   Der d2;    // ditto
}



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



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD


San Lorenzo 47, 3rd Floor, Office 5

C?rdoba, Argentina


Phone: +54 351 4217888 / +54 351 4218211

Skype: dgutson


From mjw@redhat.com  Wed Oct  8 10:57:42 2014
From: mjw@redhat.com (Mark Wielaard)
Date: Wed, 08 Oct 2014 12:57:42 +0200
Subject: [Dwarf-Discuss] C++14 and C++03 (vs C++98)
Message-ID: <1412765862.5534.8.camel@bordewijk.wildebeest.org>

Hi,

I just submitted an issue proposal for adding DW_LANG_C_plus_plus_14.
But don't have an issue number yet. See proposal below.

I also had a question about issue 120628.1 which proposes to add
DW_LANG_C_plus_plus_03. The current DWARFv4 DW_LANG_C_plus_plus says it
is for ISO C++:1998. As far as I know C++03 (unlike C++11 and C++14)
didn't add any language changes, so I think for producers and consumers
C++98 and C++03 look similar. When would consumers expect to see
DW_LANG_C_plus_plus and when DW_LANG_C_plus_plus_03?

Thanks,

Mark

Subject:  c++14 DW_LANG constant
Name:  Mark Wielaard
Email:  mjw at redhat.com
Section:  3.1  Page:  44
Type:  Enhancement

In August C++14 ISO/IEC 14882:2014(E) was adopted. Since this version of C++ adds some new language constructs and changes the semantics of some constructs it is useful for debuggers to know the source language was C++14.

Page 44, Section 3.1.1, Figure 8. Language names add:
  DW_LANG_C_plus_plus_14    ISO/IEC 14882:2014(E)

Page 172, Section 7.12, Figure 31. Language encodings add:
  DW_LANG_C_plus_plus_14    0x001X    0


From jason@redhat.com  Wed Oct  8 12:13:32 2014
From: jason@redhat.com (Jason Merrill)
Date: Wed, 08 Oct 2014 08:13:32 -0400
Subject: [Dwarf-Discuss] C++14 and C++03 (vs C++98)
In-Reply-To: <1412765862.5534.8.camel@bordewijk.wildebeest.org>
References: <1412765862.5534.8.camel@bordewijk.wildebeest.org>
Message-ID: <54352A6C.3070206@redhat.com>

On 10/08/2014 06:57 AM, Mark Wielaard wrote:
> I just submitted an issue proposal for adding DW_LANG_C_plus_plus_14.
> But don't have an issue number yet. See proposal below.
>
> I also had a question about issue 120628.1 which proposes to add
> DW_LANG_C_plus_plus_03. The current DWARFv4 DW_LANG_C_plus_plus says it
> is for ISO C++:1998. As far as I know C++03 (unlike C++11 and C++14)
> didn't add any language changes, so I think for producers and consumers
> C++98 and C++03 look similar. When would consumers expect to see
> DW_LANG_C_plus_plus and when DW_LANG_C_plus_plus_03?

Agreed, C++03 is just C++98 with some DRs.

Actually, it's not clear to me why we need multiple standard levels at 
all.  What differences are there that aren't directly expressed by new 
TAGs and such?

Jason



From mjw@redhat.com  Wed Oct  8 12:58:39 2014
From: mjw@redhat.com (Mark Wielaard)
Date: Wed, 08 Oct 2014 14:58:39 +0200
Subject: [Dwarf-Discuss] C++14 and C++03 (vs C++98)
In-Reply-To: <54352A6C.3070206@redhat.com>
References: <1412765862.5534.8.camel@bordewijk.wildebeest.org>
	<54352A6C.3070206@redhat.com>
Message-ID: <1412773119.5534.12.camel@bordewijk.wildebeest.org>

On Wed, 2014-10-08 at 08:13 -0400, Jason Merrill wrote:
> Actually, it's not clear to me why we need multiple standard levels at 
> all.  What differences are there that aren't directly expressed by new 
> TAGs and such?

It is mainly for consumers that allow users to interact with the program
described through DWARF. For example a debugger might want to know which
expressions are valid (e.g. is restrict a keyword or not). This matters
for example when someone copy/pastes some expression in the source code
from the program to be evaluated at at a certain breakpoint.

Another reason is indeed for things that aren't currently expressed in
DWARF, but could be derived from other properties. The one that comes to
mind wrt C++14 vs C++11 from our recent discussions is the concept of
trivially copyable types (earlier c++ versions treats cv-qualified types
differently from C++14, which excludes volatile cv-qualified types in
certain cases). In that specific case we could of course come up with a
proposal to express that property with a DWARF attribute that is
language (version) independent, but I don't know if we can identify all
such properties for C++14 in time before DWARFv5 is finalized and
properly evaluate it in implementations to make the need for consumers
to distinguish between different versions of the source language moot.

Cheers,

Mark


From eager@eagercon.com  Fri Oct 10 15:02:01 2014
From: eager@eagercon.com (Michael Eager)
Date: Fri, 10 Oct 2014 08:02:01 -0700
Subject: [Dwarf-Discuss] C++14 and C++03 (vs C++98)
In-Reply-To: <1412765862.5534.8.camel@bordewijk.wildebeest.org>
References: <1412765862.5534.8.camel@bordewijk.wildebeest.org>
Message-ID: <5437F4E9.80101@eagercon.com>

On 10/08/14 03:57, Mark Wielaard wrote:
> Hi,
>
> I just submitted an issue proposal for adding DW_LANG_C_plus_plus_14.
> But don't have an issue number yet. See proposal below.

Issue 141008.1 -- http://dwarfstd.org/ShowIssue.php?issue=141008.1

There has been some discussion about breaking the language description
into major/minor parts, separating the language from the version
into a different attributes.  Something to consider for DWARF Version 6,
not now.


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


