Add new DW_AT and DW_FORM codes for Fission

I'd like to add these new DW_AT and DW_FORM codes for the Fission project:

   http://gcc.gnu.org/wiki/DebugFission

We're currently working on the Fission implementation in GCC, gold,
and binutils, but I'd like to at least lay claim to the actual values
to prevent overlap with any other extensions that someone might start
working on.

In GCC, we're working on the (git-only) google/debugfission branch.
We'll be sending gold and binutils patches soon.

Any objections? Is this OK for trunk in binutils and gcc trees?

-cary


	* include/dwarf2.h (enum dwarf_form): Add Fission extensions.
	(enum dwarf_attribute): Likewise.


commit 269b973ca77ee01fec83a7bad204eecde73ca9c1
Author: Cary Coutant <ccoutant@google.com>
Date:   Sat Nov 5 01:17:06 2011 -0700

    Add new DW_AT and DW_FORM codes for Fission.

On Wed, Jan 25, 2012 at 05:54:26PM -0800, Cary Coutant wrote:
> I'd like to add these new DW_AT and DW_FORM codes for the Fission project:
> 
>    http://gcc.gnu.org/wiki/DebugFission
> 
> We're currently working on the Fission implementation in GCC, gold,
> and binutils, but I'd like to at least lay claim to the actual values
> to prevent overlap with any other extensions that someone might start
> working on.
> 
> In GCC, we're working on the (git-only) google/debugfission branch.
> We'll be sending gold and binutils patches soon.
> 
> Any objections? Is this OK for trunk in binutils and gcc trees?

If the DW_FORM_ values are meant to be in a vendor range of forms
(which DWARF4 unfortunately doesn't have), aren't they too low, i.e. isn't
there risk that eventually they'll clash with standard forms?
The forms numbers aren't limited to 0 .. 0x7f, at the expense of a slightly
bigger abbrev table you could as well use something very high, like 0x380+.
And, if you want to standardize it, I'd assume the codes would be lower
on the other side (there are still even free codes from 0x1a through to
0x1f).

	Jakub

> If the DW_FORM_ values are meant to be in a vendor range of forms
> (which DWARF4 unfortunately doesn't have), aren't they too low, i.e. isn't
> there risk that eventually they'll clash with standard forms?
> The forms numbers aren't limited to 0 .. 0x7f, at the expense of a slightly
> bigger abbrev table you could as well use something very high, like 0x380+.
> And, if you want to standardize it, I'd assume the codes would be lower
> on the other side (there are still even free codes from 0x1a through to
> 0x1f).

FORM codes aren't added very often because they do break
compatibility, so I wouldn't expect values in the 0x70-7f range to
collide with any future standard FORM codes. I did want to keep them
in the single-byte LEB128 range, although as you point out, it
wouldn't cost all that much to make them even larger. We can move them
to a higher range if you prefer.

I do intend to standardize these once we start working on DWARF-5, but
I felt it was a good idea to try them out experimentally before
reserving any standard values.

-cary

On Thu, Jan 26, 2012 at 11:18:24AM -0800, Cary Coutant wrote:
> FORM codes aren't added very often because they do break
> compatibility, so I wouldn't expect values in the 0x70-7f range to
> collide with any future standard FORM codes. I did want to keep them
> in the single-byte LEB128 range, although as you point out, it
> wouldn't cost all that much to make them even larger. We can move them
> to a higher range if you prefer.
> 
> I do intend to standardize these once we start working on DWARF-5, but
> I felt it was a good idea to try them out experimentally before
> reserving any standard values.

Especially in this case where it is primarily for experimenting with it I
think using higher values would be better, though perhaps still some that
fit into two byte ULEB128.

	Jakub

On Thu, Jan 26, 2012 at 02:04:59PM -0800, Cary Coutant wrote:
> 2012-01-26  Cary Coutant  <ccoutant@google.com>
> 
> 	* include/dwarf2.h (enum dwarf_form): Add Fission extensions.
> 	(enum dwarf_attribute): Likewise.

This is ok.

> commit 0097fed73afa307f5cfc5de9cae0d3041f66193f
> Author: Cary Coutant <ccoutant@google.com>
> Date:   Sat Nov 5 01:17:06 2011 -0700
> 
>     Add new DW_AT and DW_FORM codes for Fission.
> 
> diff --git a/include/dwarf2.h b/include/dwarf2.h
> index 37cb83f..8c0c9ed 100644
> --- a/include/dwarf2.h
> +++ b/include/dwarf2.h
> @@ -188,7 +188,11 @@ enum dwarf_form
>      DW_FORM_sec_offset = 0x17,
>      DW_FORM_exprloc = 0x18,
>      DW_FORM_flag_present = 0x19,
> -    DW_FORM_ref_sig8 = 0x20
> +    DW_FORM_ref_sig8 = 0x20,
> +    /* Extensions for Fission.  See http://gcc.gnu.org/wiki/DebugFission.  */
> +    DW_FORM_GNU_ref_index = 0x1f00,
> +    DW_FORM_GNU_addr_index = 0x1f01,
> +    DW_FORM_GNU_str_index = 0x1f02
>    };
> 
>  /* Attribute names and codes.  */
> @@ -368,6 +372,13 @@ enum dwarf_attribute
>      DW_AT_GNU_all_source_call_sites = 0x2118,
>      /* Section offset into .debug_macro section.  */
>      DW_AT_GNU_macros = 0x2119,
> +    /* Extensions for Fission.  See http://gcc.gnu.org/wiki/DebugFission.  */
> +    DW_AT_GNU_dwo_name = 0x2130,
> +    DW_AT_GNU_dwo_id = 0x2131,
> +    DW_AT_GNU_ref_base = 0x2132,
> +    DW_AT_GNU_addr_base = 0x2133,
> +    DW_AT_GNU_pubnames = 0x2134,
> +    DW_AT_GNU_pubtypes = 0x2135,
>      /* VMS extensions.  */
>      DW_AT_VMS_rtnbeg_pd_address = 0x2201,
>      /* GNAT extensions.  */

	Jakub

>> 2012-01-26  Cary Coutant  <ccoutant@google.com>
>>
>>       * include/dwarf2.h (enum dwarf_form): Add Fission extensions.
>>       (enum dwarf_attribute): Likewise.
>
> This is ok.

Thanks. I don't remember what the procedure is, though -- do I check
it in to both gcc and binutils trees, or just one and let it sync to
the other?

-cary

On Thu, Jan 26, 2012 at 02:20:12PM -0800, Cary Coutant wrote:
> >> 2012-01-26  Cary Coutant  <ccoutant@google.com>
> >>
> >>       * include/dwarf2.h (enum dwarf_form): Add Fission extensions.
> >>       (enum dwarf_attribute): Likewise.
> >
> > This is ok.
> 
> Thanks. I don't remember what the procedure is, though -- do I check
> it in to both gcc and binutils trees, or just one and let it sync to
> the other?

I think it is best to check it into both trees.

	Jakub