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
* dwarf2.def
> 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
>
> * dwarf2.def (DW_OP_AARCH64_operation): Re
> 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 operati
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 DW_CFA_undefined
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 addr
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 t
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
gdb/dwarf2-
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 ke
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 CF
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
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
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
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 usin
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 us
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 sa
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]
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 contain
17 matches
Mail list logo
