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