Re: [PATCH] dwarf2out: Emit DWARF 6 DW_AT_language_{name,version}

On Wed, Jan 08, 2025 at 02:35:56PM +0100, Mark Wielaard wrote:
> > --- gcc/dwarf2out.cc.jj	2025-01-02 11:23:35.541251268 +0100
> > +++ gcc/dwarf2out.cc	2025-01-07 10:09:16.866866563 +0100
> > @@ -8755,6 +8755,14 @@ break_out_comdat_types (dw_die_ref die)
> >          unit = new_die (DW_TAG_type_unit, NULL, NULL);
> >          add_AT_unsigned (unit, DW_AT_language,
> >                           get_AT_unsigned (comp_unit_die (), DW_AT_language));
> > +	if (unsigned lname = get_AT_unsigned (comp_unit_die (),
> > +					      DW_AT_language_name))
> > +	  {
> > +	    add_AT_unsigned (unit, DW_AT_language_name, lname);
> > +	    add_AT_unsigned (unit, DW_AT_language_version,
> > +			     get_AT_unsigned (comp_unit_die (),
> > +					      DW_AT_language_version));
> > +	  }
> 
> This relies on language_name and language_version always being set
> together. Which is the case in the code at this time. Should we assert
> that?

Worst case it will emit the useless 0 in there.
I think we should never emit DW_AT_language_version without
DW_AT_language_name, but the other way around is possible, although
only at DWARF 6 time for languages which don't care about version.
For DWARF 5 we wouldn't bother with DW_AT_language_name in that case
and just emit DW_AT_language.

> The use of language_string (lang_hooks.name) is a little clumsy, but
> already part of the current code. In the future it would be nice to
> have separate language and version hooks for this.

The advantage of that is that it also shows up in human readable form
in DW_AT_producer that way.

> Personally I would just go with the new DW_LANG_C17/C23 language code,
> they will be supported by consumers when gcc 15 is released.

As discussed, I don't think that is a good idea, because some people won't
update all the tools and just use a newer gcc.  And the advantages of
DW_LANG_C23/DW_LANG_C_plus_plus17 definitely don't outweight the pain if
using older tools (where debugging becomes really clumsy).

> The 00 for the month in C2Y is clever. Does that match the
> __STDC_VERSION__ defined?

Yes.

> Why 202400 and not 202600?

Because that is what __cplusplus is defined to for C++26 right now.
Newer than 202302 and 00 month indicates that it is just a temporary thing.

	Jakub