This is the mail archive of the
mailing list for the binutils project.
Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jiong Wang <jiong dot wang at foss dot arm dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, gdb-patches at sourceware dot org, Binutils <binutils at sourceware dot org>, "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- Date: Fri, 11 Nov 2016 20:38:59 +0100
- Subject: Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Nov 11, 2016 at 06:21:48PM +0000, Jiong Wang wrote:
> This patch introduces three AARCH64 private DWARF operations in vendor extension
> DW_OP_AARCH64_pauth 0xea
> Takes one unsigned LEB 128 Pointer Authentication Description. Bits [3:0] of
> the description contain the Authentication Action Code. All unused bits are
> initialized to 0. The operation then proceeds according to the value of the
> action code as described in the Action Code Table.
> DW_OP_AARCH64_paciasp 0xeb
> Authenticates the contents in X30/LR register as per A key for instruction
> pointer using current CFA as salt. The result is pushed onto the stack.
> DW_OP_AARCH64_paciasp_deref 0xec
> Takes one signed LEB128 offset and retrieves 8-byte contents from the address
> calculated by CFA plus this offset, the contents then authenticated as per A
> key for instruction pointer using current CFA as salt. The result is pushed
> onto the stack.
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.