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

On 28/12/16 19:54, Cary Coutant wrote: OK on this proposal and to install this patch to gcc trunk? Hi GDB, Binutils maintainer: OK on this proposal and install this patch to binutils-gdb master? include/ 2016-11-29 Richard Earnshaw Jiong Wang

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

> OK on this proposal and to install this patch to gcc trunk? > > Hi GDB, Binutils maintainer: > > OK on this proposal and install this patch to binutils-gdb master? > > include/ > 2016-11-29 Richard Earnshaw > Jiong Wang > > *

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

> 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

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

Jiong Wang writes: > Jiong Wang writes: > >> Jiong Wang writes: >> >>> On 16/11/16 14:02, Jakub Jelinek wrote: On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote: > On Wed, 2016-11-16 at 10:00 +, Jiong Wang wrote: >> The two operations DW_OP_AARCH64_paciasp and

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

Jiong Wang writes: > Jiong Wang writes: > >> On 16/11/16 14:02, Jakub Jelinek wrote: >>> On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote: On Wed, 2016-11-16 at 10:00 +, Jiong Wang wrote: > The two operations DW_OP_AARCH64_paciasp and >

Re: [Ping~][1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space

Jiong Wang writes: > On 16/11/16 14:02, Jakub Jelinek wrote: >> On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote: >>> On Wed, 2016-11-16 at 10:00 +, Jiong Wang wrote: The two operations DW_OP_AARCH64_paciasp and DW_OP_AARCH64_paciasp_deref were designed as

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

On 01/12/16 10:42, Richard Earnshaw (lists) wrote: On 30/11/16 21:43, Cary Coutant wrote: How about if instead of special DW_OP codes, you instead define a new virtual register that contains the mangled return address? If the rule for that virtual register is anything other than

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

On 30/11/16 21:43, Cary Coutant wrote: > How about if instead of special DW_OP codes, you instead define a new > virtual register that contains the mangled return address? If the rule > for that virtual register is anything other than DW_CFA_undefined, > you'd expect to find the mangled return

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

How about if instead of special DW_OP codes, you instead define a new virtual register that contains the mangled return address? If the rule for that virtual register is anything other than DW_CFA_undefined, you'd expect to find the mangled return address using that rule; otherwise, you would use

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

On Wed, Nov 30, 2016 at 11:15:22AM +, Jiong Wang wrote: > > Hi GDB, Binutils maintainer: > > OK on this proposal and install this patch to binutils-gdb master? > This proposal is good to GDB, as long as you add a gdbarch hook and move the code handling DW_CFA_GNU_window_save in

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

On 16/11/16 14:02, Jakub Jelinek wrote: On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote: On Wed, 2016-11-16 at 10:00 +, Jiong Wang wrote: The two operations DW_OP_AARCH64_paciasp and DW_OP_AARCH64_paciasp_deref were designed as shortcut operations when LR is signed with A

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

On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote: > On Wed, 2016-11-16 at 10:00 +, Jiong Wang wrote: > > The two operations DW_OP_AARCH64_paciasp and DW_OP_AARCH64_paciasp_deref > > were > > designed as shortcut operations when LR is signed with A key and using > > function's

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

On Wed, 2016-11-16 at 10:00 +, Jiong Wang wrote: > The two operations DW_OP_AARCH64_paciasp and DW_OP_AARCH64_paciasp_deref > were > designed as shortcut operations when LR is signed with A key and using > function's CFA as salt. This is the default behaviour of return address > signing so

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

On 15/11/16 19:25, Richard Earnshaw (lists) wrote: On 15/11/16 16:48, Jiong Wang wrote: On 15/11/16 16:18, Jakub Jelinek wrote: I know nothing about the aarch64 return address signing, would all 3 or say 2 usually appear together without any separate pc advance, or are they all going to appear

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

On 15/11/16 16:48, Jiong Wang wrote: > > > On 15/11/16 16:18, Jakub Jelinek wrote: >> On Tue, Nov 15, 2016 at 04:00:40PM +, Jiong Wang wrote: >Takes one signed LEB128 offset and retrieves 8-byte contents > from the address >calculated by CFA plus this offset, the contents

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

On 15/11/16 16:18, Jakub Jelinek wrote: On Tue, Nov 15, 2016 at 04:00:40PM +, Jiong Wang wrote: 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

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

On 15/11/16 16:18, Jakub Jelinek wrote: On Tue, Nov 15, 2016 at 04:00:40PM +, Jiong Wang wrote: 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

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

On Tue, Nov 15, 2016 at 04:00:40PM +, Jiong Wang wrote: > >> 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

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

On 11/11/16 19:38, Jakub Jelinek wrote: On Fri, Nov 11, 2016 at 06:21:48PM +, 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]

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

On Fri, Nov 11, 2016 at 06:21:48PM +, 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

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

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.