This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space
- From: Cary Coutant <ccoutant at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Jiong Wang <jiong dot wang at foss dot arm dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, GDB <gdb-patches at sourceware dot org>, Binutils <binutils at sourceware dot org>, "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- Date: Wed, 28 Dec 2016 11:48:23 -0800
- Subject: Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space
- Authentication-results: sourceware.org; auth=none
- References: <c9da17a6-c3de-4466-c023-4e4ddbe38efb@foss.arm.com> <72418e98-a400-c503-e8ce-c3fbe1ecc4a7@foss.arm.com> <20161111193859.GJ3541@tucnak.redhat.com>
> I'd like to point out that especially the vendor range of DW_OP_* is
> extremely scarce resource, we have only a couple of unused values, so taking
> 3 out of the remaining unused 12 for a single architecture is IMHO too much.
> Can't you use just a single opcode and encode which of the 3 operations it is
> in say the low 2 bits of a LEB 128 operand?
> We'll likely need to do RSN some multiplexing even for the generic GNU
> opcodes if we need just a few further ones (say 0xff as an extension,
> followed by uleb128 containing the opcode - 0xff).
> In the non-vendor area we still have 54 values left, so there is more space
> for future expansion.
Most of the Gnu extensions have been adopted into the standard as of DWARF 5:
/* GNU extensions. */
DW_OP (DW_OP_GNU_push_tls_address, 0xe0)
/* The following is for marking variables that are uninitialized. */
DW_OP (DW_OP_GNU_uninit, 0xf0)
DW_OP (DW_OP_GNU_encoded_addr, 0xf1)
/* The GNU implicit pointer extension.
See http://www.dwarfstd.org/ShowIssue.php?issue=100831.1&type=open . */
DW_OP (DW_OP_GNU_implicit_pointer, 0xf2)
/* The GNU entry value extension.
See http://www.dwarfstd.org/ShowIssue.php?issue=100909.1&type=open . */
DW_OP (DW_OP_GNU_entry_value, 0xf3)
/* The GNU typed stack extension.
See http://www.dwarfstd.org/doc/040408.1.html . */
DW_OP (DW_OP_GNU_const_type, 0xf4)
DW_OP (DW_OP_GNU_regval_type, 0xf5)
DW_OP (DW_OP_GNU_deref_type, 0xf6)
DW_OP (DW_OP_GNU_convert, 0xf7)
DW_OP (DW_OP_GNU_reinterpret, 0xf9)
/* The GNU parameter ref extension. */
DW_OP (DW_OP_GNU_parameter_ref, 0xfa)
/* Extensions for Fission. See http://gcc.gnu.org/wiki/DebugFission. */
DW_OP (DW_OP_GNU_addr_index, 0xfb)
DW_OP (DW_OP_GNU_const_index, 0xfc)
Of these, I think only DW_OP_GNU_uninit and DW_OP_GNU_encoded_addr
remain as Gnu extensions. The rest could be deprecated as of DWARF 5,
and, if necessary, reused for other purposes in DWARF 6 and later.
Depending on how aggressive we want to be with deprecation, we could
even declare that they are available for reuse in DWARF 5 and later,
as long as the Gnu toolchain uses only the new standard values when
generating DWARF 5. That frees up 11 more opcodes.
-cary