[1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space

[Jakub Jelinek]

On Fri, Nov 11, 2016 at 06:21:48PM +0000, Jiong Wang wrote:
> This patch introduces three AARCH64 private DWARF operations in vendor extension
> space.
> 
> 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.

	Jakub