* [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space [not found] <c9da17a6-c3de-4466-c023-4e4ddbe38efb@foss.arm.com> @ 2016-11-11 18:22 ` Jiong Wang 2016-11-11 19:39 ` Jakub Jelinek 0 siblings, 1 reply; 25+ messages in thread From: Jiong Wang @ 2016-11-11 18:22 UTC (permalink / raw) To: gcc-patches, gdb-patches, Binutils; +Cc: Richard Earnshaw (lists) [-- Attachment #1: Type: text/plain, Size: 3591 bytes --] 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. Action Code Table ================================== Action Code | Note ---------------------------------- 0 | Pops a single 8-byte operand from the stack representing a | signed instruction pointer, "drops" the authentication | signature and pushes the value onto stack. ---------------------------------- 1 | Pops a single 8-byte operand from the stack representing a | signed data pointer, "drops" the authentication signature | and pushes the value on to stack. ---------------------------------- 2 | Bits [7:4] of the Pointer Authentication Description contain | an Authentication Key Index. The operation then pops the top | two stack entries. The first is an 8-byte value to be | authenticated. The second is an 8-byte salt. The first value | is then authenticated as per the Authentication Key Index | using the salt. The result is pushed onto stack. Authentication Key Index ================================= 0 | A key for instruction pointer. --------------------------------- 1 | B key for instruction pointer. --------------------------------- 2 | A key for data pointer. --------------------------------- 3 | B key for data pointer. --------------------------------- 4 | A key for general pointer. DW_OP_AARCH64_pauth is designed to offer general description for all scenarios. DW_OP_AARCH64_paciasp and DW_OP_AARCH64_paciasp_deref are two shortcut operations for return address signing. They offer more compact debug frame encoding. For DWARF operation vendor extension space between DW_OP_lo_user and DW_OP_hi_user, I think vendor is free to reserve any number and numbers for one vender can overlap with the other, as operations for different vendors are not supposed to co-exist. One exception is that GNU toolchain have reserved some numbers inside this space (DW_OP_GNU*), so vendor's numbers need to avoid overlapping with them. For these three numbers, they are not used in LLVM's implementation. NOTE: the assigned values are provisional, we may need to change them if they are found to be in conflict with on other toolchains. Please review, Thanks. include/ 2016-11-09 Richard Earnshaw<richard.earnshaw@arm.com> Jiong Wang<jiong.wang@arm.com> * dwarf2.def (DW_OP_AARCH64_pauth): Reserve the number 0xea. (DW_OP_AARCH64_paciasp): Reserve the number 0xeb. (Dw_OP_AARCH64_paciasp_deref): Reserve the number 0xec. [-- Attachment #2: 1.patch --] [-- Type: text/x-patch, Size: 958 bytes --] diff --git a/include/dwarf2.def b/include/dwarf2.def index 5241fe8615e0e3b288fee80c08a67723686ef411..8eaa90c3b4748ecfc025a6c2dd6afcd5fd80be28 100644 --- a/include/dwarf2.def +++ b/include/dwarf2.def @@ -631,6 +631,16 @@ DW_OP (DW_OP_HP_unmod_range, 0xe5) DW_OP (DW_OP_HP_tls, 0xe6) /* PGI (STMicroelectronics) extensions. */ DW_OP (DW_OP_PGI_omp_thread_num, 0xf8) +/* ARM extension for pointer authentication + DW_OP_AARCH64_pauth: takes one uleb128 operand which is authentication + descriptor. Perform actions indicated by the descriptor. + DW_OP_AARCH64_paciasp: no operand. Authenticate value in X30/LR using A key + and CFA as salt. + DW_OP_AARCH64_paciasp_deref: takes one sleb128 operand as offset. + Authenticate value in [CFA + offset] using A key and salt is CFA. */ +DW_OP (DW_OP_AARCH64_pauth, 0xea) +DW_OP (DW_OP_AARCH64_paciasp, 0xeb) +DW_OP (DW_OP_AARCH64_paciasp_deref, 0xec) DW_END_OP DW_FIRST_ATE (DW_ATE_void, 0x0) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-11-11 18:22 ` [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space Jiong Wang @ 2016-11-11 19:39 ` Jakub Jelinek 2016-11-15 16:00 ` Jiong Wang 2016-12-28 19:48 ` Cary Coutant 0 siblings, 2 replies; 25+ messages in thread From: Jakub Jelinek @ 2016-11-11 19:39 UTC (permalink / raw) To: Jiong Wang; +Cc: gcc-patches, gdb-patches, Binutils, Richard Earnshaw (lists) 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-11-11 19:39 ` Jakub Jelinek @ 2016-11-15 16:00 ` Jiong Wang 2016-11-15 16:18 ` Jakub Jelinek 2016-12-28 19:48 ` Cary Coutant 1 sibling, 1 reply; 25+ messages in thread From: Jiong Wang @ 2016-11-15 16:00 UTC (permalink / raw) To: Jakub Jelinek Cc: gcc-patches, gdb-patches, Binutils, Richard Earnshaw (lists) On 11/11/16 19:38, Jakub Jelinek wrote: > 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 Seperate DWARF operations are introduced instead of combining all of them into one are mostly because these operations are going to be used for most of the functions once return address signing are enabled, and they are used for describing frame unwinding that they will go into unwind table for C++ program or C program compiled with -fexceptions, the impact on unwind table size is significant. So I was trying to lower the unwind table size overhead as much as I can. IMHO, three numbers actually is not that much for one architecture in DWARF operation vendor extension space as vendors can overlap with each other. The only painful thing from my understand is there are platform vendors, for example "GNU" and "LLVM" etc, for which architecture vendor can't overlap with. In include/dwarf2.def, I saw DW_OP_GNU* has reserved 13, DW_OP_HP* has reserved 7 and DW_OP_PGI has reserved 1. So for an alternative approach, can these AArch64 extensions overlap and reuse those numbers reserved for DW_OP_HP* ? for example 0xe4, 0xe5, 0xe6. I am even thinking GNU toolchain makes the 8 numbers reserved by existed DW_OP_HP* and DW_OP_SGI* as architecture vendor area and allow multiplexing on them for different architectures. This may offer more flexibilities for architecture vendors. Under current code base, my search shows the overlap should be safe inside GCC/GDB and we only needs minor disassemble tweak in Binutils. Thanks. Regards, Jiong ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-11-15 16:00 ` Jiong Wang @ 2016-11-15 16:18 ` Jakub Jelinek 2016-11-15 16:48 ` Jiong Wang 2016-11-15 16:51 ` Jiong Wang 0 siblings, 2 replies; 25+ messages in thread From: Jakub Jelinek @ 2016-11-15 16:18 UTC (permalink / raw) To: Jiong Wang, mjw Cc: gcc-patches, gdb-patches, Binutils, Richard Earnshaw (lists) On Tue, Nov 15, 2016 at 04:00:40PM +0000, 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 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. > > Seperate DWARF operations are introduced instead of combining all of them into > one are mostly because these operations are going to be used for most of the > functions once return address signing are enabled, and they are used for > describing frame unwinding that they will go into unwind table for C++ program > or C program compiled with -fexceptions, the impact on unwind table size is > significant. So I was trying to lower the unwind table size overhead as much as > I can. > > IMHO, three numbers actually is not that much for one architecture in DWARF > operation vendor extension space as vendors can overlap with each other. The > only painful thing from my understand is there are platform vendors, for example > "GNU" and "LLVM" etc, for which architecture vendor can't overlap with. For DW_OP_*, there aren't two vendor ranges like e.g. in ELF, there is just one range, so ideally the opcodes would be unique everywhere, if not, there is just a single GNU vendor, there is no separate range for Aarch64, that can overlap with range for x86_64, and powerpc, etc. Perhaps we could declare that certain opcode subrange for the GNU vendor is architecture specific and document that the meaning of opcodes in that range and count/encoding of their arguments depends on the architecture, but then we should document how to figure out the architecture too (e.g. for ELF base it on the containing EM_*). All the tools that look at DWARF (readelf, objdump, eu-readelf, libdw, libunwind, gdb, dwz, ...) would need to agree on that though. 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 frequently and at different pcs? Perhaps if there is just 1 opcode and has all the info encoded just in one bigger uleb128 or something similar... Jakub ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-11-15 16:18 ` Jakub Jelinek @ 2016-11-15 16:48 ` Jiong Wang 2016-11-15 19:25 ` Richard Earnshaw (lists) 2016-11-15 16:51 ` Jiong Wang 1 sibling, 1 reply; 25+ messages in thread From: Jiong Wang @ 2016-11-15 16:48 UTC (permalink / raw) To: Jakub Jelinek, mjw Cc: gcc-patches, gdb-patches, Binutils, Richard Earnshaw (lists) On 15/11/16 16:18, Jakub Jelinek wrote: > On Tue, Nov 15, 2016 at 04:00:40PM +0000, 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 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. >> Seperate DWARF operations are introduced instead of combining all of them into >> one are mostly because these operations are going to be used for most of the >> functions once return address signing are enabled, and they are used for >> describing frame unwinding that they will go into unwind table for C++ program >> or C program compiled with -fexceptions, the impact on unwind table size is >> significant. So I was trying to lower the unwind table size overhead as much as >> I can. >> >> IMHO, three numbers actually is not that much for one architecture in DWARF >> operation vendor extension space as vendors can overlap with each other. The >> only painful thing from my understand is there are platform vendors, for example >> "GNU" and "LLVM" etc, for which architecture vendor can't overlap with. > For DW_OP_*, there aren't two vendor ranges like e.g. in ELF, there is just > one range, so ideally the opcodes would be unique everywhere, if not, there > is just a single GNU vendor, there is no separate range for Aarch64, that > can overlap with range for x86_64, and powerpc, etc. > > Perhaps we could declare that certain opcode subrange for the GNU vendor is > architecture specific and document that the meaning of opcodes in that range > and count/encoding of their arguments depends on the architecture, but then > we should document how to figure out the architecture too (e.g. for ELF > base it on the containing EM_*). All the tools that look at DWARF (readelf, > objdump, eu-readelf, libdw, libunwind, gdb, dwz, ...) would need to agree on that > though. > > 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 frequently and at different pcs? I think it's the latter, the DW_OP_AARCH64_paciasp and DW_OP_AARCH64_paciasp_deref are going to appear frequently and at different pcs. For example, the following function prologue, there are three instructions at 0x0, 0x4, 0x8. After the first instruction at 0x0, LR/X30 will be mangled. The "paciasp" always mangle LR register using SP as salt and write back the value into LR. We then generate DW_OP_AARCH64_paciasp to notify any unwinder that the original LR is mangled in this way so they can unwind the original value properly. After the second instruction at 0x4, The mangled value of LR/X30 will be pushed on to stack, unlike usual .cfi_offset, the unwind rule for LR/X30 becomes: first fetch the mangled value from stack offset -16, then do whatever to restore the original value from the mangled value. This is represented by (DW_OP_AARCH64_paciasp_deref, offset). .cfi_startproc 0x0 paciasp (this instruction sign return address register LR/X30) .cfi_val_expression 30, DW_OP_AARCH64_paciasp 0x4 stp x29, x30, [sp, -32]! .cfi_val_expression 30, DW_OP_AARCH64_paciasp_deref, -16 .cfi_offset 29, -32 .cfi_def_cfa_offset 32 0x8 add x29, sp, 0 > Perhaps if there is just 1 > opcode and has all the info encoded just in one bigger uleb128 or something > similar... ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-11-15 16:48 ` Jiong Wang @ 2016-11-15 19:25 ` Richard Earnshaw (lists) 2016-11-16 10:00 ` Jiong Wang 0 siblings, 1 reply; 25+ messages in thread From: Richard Earnshaw (lists) @ 2016-11-15 19:25 UTC (permalink / raw) To: Jiong Wang, Jakub Jelinek, mjw; +Cc: gcc-patches, gdb-patches, Binutils 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 +0000, 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 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. >>> Seperate DWARF operations are introduced instead of combining all >>> of them into >>> one are mostly because these operations are going to be used for most >>> of the >>> functions once return address signing are enabled, and they are used for >>> describing frame unwinding that they will go into unwind table for >>> C++ program >>> or C program compiled with -fexceptions, the impact on unwind table >>> size is >>> significant. So I was trying to lower the unwind table size overhead >>> as much as >>> I can. >>> >>> IMHO, three numbers actually is not that much for one architecture >>> in DWARF >>> operation vendor extension space as vendors can overlap with each >>> other. The >>> only painful thing from my understand is there are platform vendors, >>> for example >>> "GNU" and "LLVM" etc, for which architecture vendor can't overlap with. >> For DW_OP_*, there aren't two vendor ranges like e.g. in ELF, there is >> just >> one range, so ideally the opcodes would be unique everywhere, if not, >> there >> is just a single GNU vendor, there is no separate range for Aarch64, that >> can overlap with range for x86_64, and powerpc, etc. >> >> Perhaps we could declare that certain opcode subrange for the GNU >> vendor is >> architecture specific and document that the meaning of opcodes in that >> range >> and count/encoding of their arguments depends on the architecture, but >> then >> we should document how to figure out the architecture too (e.g. for ELF >> base it on the containing EM_*). All the tools that look at DWARF >> (readelf, >> objdump, eu-readelf, libdw, libunwind, gdb, dwz, ...) would need to >> agree on that >> though. >> >> 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 frequently and at different pcs? > > I think it's the latter, the DW_OP_AARCH64_paciasp and > DW_OP_AARCH64_paciasp_deref are going to appear frequently and at > different pcs. > For example, the following function prologue, there are three > instructions > at 0x0, 0x4, 0x8. > > After the first instruction at 0x0, LR/X30 will be mangled. The > "paciasp" always > mangle LR register using SP as salt and write back the value into LR. > We then generate > DW_OP_AARCH64_paciasp to notify any unwinder that the original LR is > mangled in this > way so they can unwind the original value properly. > > After the second instruction at 0x4, The mangled value of LR/X30 will > be pushed on > to stack, unlike usual .cfi_offset, the unwind rule for LR/X30 becomes: > first fetch the > mangled value from stack offset -16, then do whatever to restore the > original value > from the mangled value. This is represented by > (DW_OP_AARCH64_paciasp_deref, offset). > > .cfi_startproc > 0x0 paciasp (this instruction sign return address register LR/X30) > .cfi_val_expression 30, DW_OP_AARCH64_paciasp > 0x4 stp x29, x30, [sp, -32]! > .cfi_val_expression 30, DW_OP_AARCH64_paciasp_deref, -16 > .cfi_offset 29, -32 > .cfi_def_cfa_offset 32 > 0x8 add x29, sp, 0 > Now I'm confused. I was thinking that we needed one opcode for the sign operation in the prologue and one for the unsign/validate operation in the epilogue (to support non-call exceptions. But why do we need a separate code to say that a previously signed value has now been pushed on the stack? Surely that's just a normal store operation that can be tracked through the unwinding state machine. I was expecting the third opcode to be needed for the special operations that are not frequently used by the compiler. R. >> Perhaps if there is just 1 >> opcode and has all the info encoded just in one bigger uleb128 or >> something >> similar... > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-11-15 19:25 ` Richard Earnshaw (lists) @ 2016-11-16 10:00 ` Jiong Wang 2016-11-16 13:55 ` Mark Wielaard 0 siblings, 1 reply; 25+ messages in thread From: Jiong Wang @ 2016-11-16 10:00 UTC (permalink / raw) To: Richard Earnshaw (lists), Jakub Jelinek, mjw Cc: gcc-patches, gdb-patches, Binutils 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 frequently and at different pcs? >> >> I think it's the latter, the DW_OP_AARCH64_paciasp and >> DW_OP_AARCH64_paciasp_deref are going to appear frequently and at >> different pcs. >> For example, the following function prologue, there are three >> instructions >> at 0x0, 0x4, 0x8. >> >> After the first instruction at 0x0, LR/X30 will be mangled. The >> "paciasp" always >> mangle LR register using SP as salt and write back the value into LR. >> We then generate >> DW_OP_AARCH64_paciasp to notify any unwinder that the original LR is >> mangled in this >> way so they can unwind the original value properly. >> >> After the second instruction at 0x4, The mangled value of LR/X30 will >> be pushed on >> to stack, unlike usual .cfi_offset, the unwind rule for LR/X30 becomes: >> first fetch the >> mangled value from stack offset -16, then do whatever to restore the >> original value >> from the mangled value. This is represented by >> (DW_OP_AARCH64_paciasp_deref, offset). >> >> .cfi_startproc >> 0x0 paciasp (this instruction sign return address register LR/X30) >> .cfi_val_expression 30, DW_OP_AARCH64_paciasp >> 0x4 stp x29, x30, [sp, -32]! >> .cfi_val_expression 30, DW_OP_AARCH64_paciasp_deref, -16 >> .cfi_offset 29, -32 >> .cfi_def_cfa_offset 32 >> 0x8 add x29, sp, 0 >> > > Now I'm confused. > > I was thinking that we needed one opcode for the sign operation in the > prologue and one for the unsign/validate operation in the epilogue (to > support non-call exceptions. IMO, non-call exceptions is fine, it looks to me doesn't need extra description as for non-call exceptions (exceptions thrown from signal handler) the key point is how to unwind across signal frame. For libgcc EH unwinder, when normal unwinding failed, it will fall back to architecture unwinding hook which restore some information from signal frame which is just on top of the signal handler's frame. I can see AArch64 implementation will setup return address column like the following logic where "sc->pc" is initialized by kernel and it's not signed therefore should sucess on further unwinding. fs->regs.reg[__LIBGCC_DWARF_ALT_FRAME_RETURN_COLUMN__].how = REG_SAVED_VAL_OFFSET; fs->regs.reg[__LIBGCC_DWARF_ALT_FRAME_RETURN_COLUMN__].loc.offset = (_Unwind_Ptr) (sc->pc) - new_cfa; > But why do we need a separate code to say > that a previously signed value has now been pushed on the stack? Surely > that's just a normal store operation that can be tracked through the > unwinding state machine. I was thinking the same thing, but found it doesn't work. My understanding of frame unwinding described at DWARF specification is: there are two steps for frame unwinding. The first step is to calculate register restore rules. Unwinder scans register rules from function start to the unwinding PC, one rule will be *overridden* by the next for the same register, there is *no inheritance*. The second step is then to evaluate all the final rules collected at the unwinding PC. According to the rule, either fetch the value from stack or evaluate the value on DWARF expression stack etc. I also had tried to modify ".cfi_val_expression" at offset 0x4 in above example into ".cfi_offset 30, -24", libgcc EH unwinder just doesn't work. > > I was expecting the third opcode to be needed for the special operations > that are not frequently used by the compiler. 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 is expected to be used for most of the time. DW_OP_AARCH64_pauth is designed as a generic operation that allow describing pointer signing on any value using any salt and key in case we can't use the shortcut operations we can use this. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-11-16 10:00 ` Jiong Wang @ 2016-11-16 13:55 ` Mark Wielaard 2016-11-16 14:02 ` Jakub Jelinek 0 siblings, 1 reply; 25+ messages in thread From: Mark Wielaard @ 2016-11-16 13:55 UTC (permalink / raw) To: Jiong Wang Cc: Richard Earnshaw (lists), Jakub Jelinek, gcc-patches, gdb-patches, Binutils On Wed, 2016-11-16 at 10:00 +0000, 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 is expected to be used for most of the time. DW_OP_AARCH64_pauth > is designed as a generic operation that allow describing pointer signing on > any value using any salt and key in case we can't use the shortcut operations > we can use this. I admit to not fully understand the salting/keying involved. But given that the DW_OP space is really tiny, so we would like to not eat up too many of them for new opcodes. And given that introducing any new DW_OPs using for CFI unwinding will break any unwinder anyway causing us to update them all for this new feature. Have you thought about using a new CIE augmentation string character for describing that the return address/link register used by a function/frame is salted/keyed? This seems a good description of CIE records and augmentation characters: http://www.airs.com/blog/archives/460 It obviously also involves updating all unwinders to understand the new augmentation character (and possible arguments). But it might be more generic and saves us from using up too many DW_OPs. Cheers, Mark ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-11-16 13:55 ` Mark Wielaard @ 2016-11-16 14:02 ` Jakub Jelinek 2016-11-30 11:15 ` Jiong Wang 2016-11-30 21:44 ` Cary Coutant 0 siblings, 2 replies; 25+ messages in thread From: Jakub Jelinek @ 2016-11-16 14:02 UTC (permalink / raw) To: Mark Wielaard Cc: Jiong Wang, Richard Earnshaw (lists), gcc-patches, gdb-patches, Binutils On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote: > On Wed, 2016-11-16 at 10:00 +0000, 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 is expected to be used for most of the time. DW_OP_AARCH64_pauth > > is designed as a generic operation that allow describing pointer signing on > > any value using any salt and key in case we can't use the shortcut operations > > we can use this. > > I admit to not fully understand the salting/keying involved. But given > that the DW_OP space is really tiny, so we would like to not eat up too > many of them for new opcodes. And given that introducing any new DW_OPs > using for CFI unwinding will break any unwinder anyway causing us to > update them all for this new feature. Have you thought about using a new > CIE augmentation string character for describing that the return > address/link register used by a function/frame is salted/keyed? > > This seems a good description of CIE records and augmentation > characters: http://www.airs.com/blog/archives/460 > > It obviously also involves updating all unwinders to understand the new > augmentation character (and possible arguments). But it might be more > generic and saves us from using up too many DW_OPs. From what I understood, the return address is not always scrambled, so it doesn't apply to the whole function, just to most of it (except for an insn in the prologue and some in the epilogue). So I think one op is needed. But can't it be just a toggable flag whether the return address is scrambled + some arguments to it? Thus DW_OP_AARCH64_scramble .uleb128 0 would mean that the default way of scrambling starts here (if not already active) or any kind of scrambling ends here (if already active), and DW_OP_AARCH64_scramble .uleb128 non-zero would be whatever encoding you need to represent details of the less common variants with details what to do. Then you'd just hook through some MD_* macro in the unwinder the descrambling operation if the scrambling is active at the insns you unwind on. Jakub ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-11-16 14:02 ` Jakub Jelinek @ 2016-11-30 11:15 ` Jiong Wang 2016-11-30 18:25 ` Yao Qi ` (2 more replies) 2016-11-30 21:44 ` Cary Coutant 1 sibling, 3 replies; 25+ messages in thread From: Jiong Wang @ 2016-11-30 11:15 UTC (permalink / raw) To: Jakub Jelinek, Mark Wielaard Cc: Richard Earnshaw (lists), gcc-patches, gdb-patches, Binutils [-- Attachment #1: Type: text/plain, Size: 4006 bytes --] 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 +0000, 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 is expected to be used for most of the time. DW_OP_AARCH64_pauth >>> is designed as a generic operation that allow describing pointer signing on >>> any value using any salt and key in case we can't use the shortcut operations >>> we can use this. >> >> I admit to not fully understand the salting/keying involved. But given >> that the DW_OP space is really tiny, so we would like to not eat up too >> many of them for new opcodes. And given that introducing any new DW_OPs >> using for CFI unwinding will break any unwinder anyway causing us to >> update them all for this new feature. Have you thought about using a new >> CIE augmentation string character for describing that the return >> address/link register used by a function/frame is salted/keyed? >> >> This seems a good description of CIE records and augmentation >> characters:http://www.airs.com/blog/archives/460 >> >> It obviously also involves updating all unwinders to understand the new >> augmentation character (and possible arguments). But it might be more >> generic and saves us from using up too many DW_OPs. > > From what I understood, the return address is not always scrambled, so > it doesn't apply to the whole function, just to most of it (except for > an insn in the prologue and some in the epilogue). So I think one op is > needed. But can't it be just a toggable flag whether the return address > is scrambled + some arguments to it? > Thus DW_OP_AARCH64_scramble .uleb128 0 would mean that the default > way of scrambling starts here (if not already active) or any kind of > scrambling ends here (if already active), and > DW_OP_AARCH64_scramble .uleb128 non-zero would be whatever encoding you need > to represent details of the less common variants with details what to do. > Then you'd just hook through some MD_* macro in the unwinder the > descrambling operation if the scrambling is active at the insns you unwind > on. > > Jakub Hi Mark, Jakub: Thanks very much for the suggestions. I have done some experiments on your ideas and am thinking it's good to combine them together. The use of DW_CFA instead of DW_OP can avoid building all information from scratch at each unwind location, while we can indicate the signing key index through new AArch64 CIE augmentation 'B'. This new approach reduce the unwind table size overhead from ~25% to ~5% when return address signing enabled, it also largely simplified dwarf generation code for return address signing. As one new DWARF call frame instruction is needed for AArch64, I want to reuse DW_CFA_GNU_window_save to save the space. It is in vendor extension space and used for Sparc only, I think it make sense to reuse it for AArch64. On AArch64, DW_CFA_GNU_window_save toggle return address sign status which kept in a new boolean type column in DWARF table, so DW_CFA_GNU_window_save takes no argument on AArch64, the same as on Sparc, this makes no difference to those existed encoding, length calculation code. Meanwhile one new DWARF expression operation number is still needed for AArch64, it's useful for describing those complex pointer signing scenarios and it will be used to multiplex some further extensions on AArch64. 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 <rearnsha@arm.com> Jiong Wang <jiong.wang@arm.com> * dwarf2.def (DW_OP_AARCH64_operation): Reserve the number 0xea. [-- Attachment #2: dw.patch --] [-- Type: text/x-diff, Size: 1119 bytes --] diff --git a/include/dwarf2.def b/include/dwarf2.def index bb916ca238221151cf49359c25fd92643c7e60af..f3892a20da1fe13ddb419e5d7eda07f2c8d8b0c6 100644 --- a/include/dwarf2.def +++ b/include/dwarf2.def @@ -684,6 +684,12 @@ DW_OP (DW_OP_HP_unmod_range, 0xe5) DW_OP (DW_OP_HP_tls, 0xe6) /* PGI (STMicroelectronics) extensions. */ DW_OP (DW_OP_PGI_omp_thread_num, 0xf8) +/* AARCH64 extensions. + DW_OP_AARCH64_operation takes one mandatory unsigned LEB128 operand. + Bits[6:0] of this operand is the action code, all others bits are initialized + to 0 except explicitly documented for one action. Please refer AArch64 DWARF + ABI documentation for details. */ +DW_OP (DW_OP_AARCH64_operation, 0xea) DW_END_OP DW_FIRST_ATE (DW_ATE_void, 0x0) @@ -765,7 +771,8 @@ DW_CFA (DW_CFA_hi_user, 0x3f) /* SGI/MIPS specific. */ DW_CFA (DW_CFA_MIPS_advance_loc8, 0x1d) -/* GNU extensions. */ +/* GNU extensions. + NOTE: DW_CFA_GNU_window_save is multiplexed on Sparc and AArch64. */ DW_CFA (DW_CFA_GNU_window_save, 0x2d) DW_CFA (DW_CFA_GNU_args_size, 0x2e) DW_CFA (DW_CFA_GNU_negative_offset_extended, 0x2f) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-11-30 11:15 ` Jiong Wang @ 2016-11-30 18:25 ` Yao Qi 2016-12-12 13:40 ` [Ping~][1/9][RFC][DWARF] " Jiong Wang 2016-12-28 19:54 ` [1/9][RFC][DWARF] " Cary Coutant 2 siblings, 0 replies; 25+ messages in thread From: Yao Qi @ 2016-11-30 18:25 UTC (permalink / raw) To: Jiong Wang Cc: Jakub Jelinek, Mark Wielaard, Richard Earnshaw (lists), gcc-patches, gdb-patches, Binutils On Wed, Nov 30, 2016 at 11:15:22AM +0000, 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-frame.c:execute_cfa_program to sparc-tdep.c or/and sparc64-tdep.c. -- Yao (é½å°§) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [Ping~][1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-11-30 11:15 ` Jiong Wang 2016-11-30 18:25 ` Yao Qi @ 2016-12-12 13:40 ` Jiong Wang 2016-12-19 13:59 ` [Ping^2][1/9][RFC][DWARF] " Jiong Wang 2016-12-28 19:54 ` [1/9][RFC][DWARF] " Cary Coutant 2 siblings, 1 reply; 25+ messages in thread From: Jiong Wang @ 2016-12-12 13:40 UTC (permalink / raw) To: Jakub Jelinek, Mark Wielaard Cc: Richard Earnshaw (lists), gcc-patches, gdb-patches, Binutils 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 +0000, 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 is expected to be used for most of the time. DW_OP_AARCH64_pauth >>>> is designed as a generic operation that allow describing pointer signing on >>>> any value using any salt and key in case we can't use the shortcut operations >>>> we can use this. >>> >>> I admit to not fully understand the salting/keying involved. But given >>> that the DW_OP space is really tiny, so we would like to not eat up too >>> many of them for new opcodes. And given that introducing any new DW_OPs >>> using for CFI unwinding will break any unwinder anyway causing us to >>> update them all for this new feature. Have you thought about using a new >>> CIE augmentation string character for describing that the return >>> address/link register used by a function/frame is salted/keyed? >>> >>> This seems a good description of CIE records and augmentation >>> characters:http://www.airs.com/blog/archives/460 >>> >>> It obviously also involves updating all unwinders to understand the new >>> augmentation character (and possible arguments). But it might be more >>> generic and saves us from using up too many DW_OPs. >> >> From what I understood, the return address is not always scrambled, so >> it doesn't apply to the whole function, just to most of it (except for >> an insn in the prologue and some in the epilogue). So I think one op is >> needed. But can't it be just a toggable flag whether the return address >> is scrambled + some arguments to it? >> Thus DW_OP_AARCH64_scramble .uleb128 0 would mean that the default >> way of scrambling starts here (if not already active) or any kind of >> scrambling ends here (if already active), and >> DW_OP_AARCH64_scramble .uleb128 non-zero would be whatever encoding you need >> to represent details of the less common variants with details what to do. >> Then you'd just hook through some MD_* macro in the unwinder the >> descrambling operation if the scrambling is active at the insns you unwind >> on. >> >> Jakub > > Hi Mark, Jakub: > > Thanks very much for the suggestions. > > I have done some experiments on your ideas and am thinking it's good to > combine them together. The use of DW_CFA instead of DW_OP can avoid building > all information from scratch at each unwind location, while we can indicate > the signing key index through new AArch64 CIE augmentation 'B'. This new > approach reduce the unwind table size overhead from ~25% to ~5% when return > address signing enabled, it also largely simplified dwarf generation code for > return address signing. > > As one new DWARF call frame instruction is needed for AArch64, I want to reuse > DW_CFA_GNU_window_save to save the space. It is in vendor extension space and > used for Sparc only, I think it make sense to reuse it for AArch64. On > AArch64, DW_CFA_GNU_window_save toggle return address sign status which kept > in a new boolean type column in DWARF table, so DW_CFA_GNU_window_save takes > no argument on AArch64, the same as on Sparc, this makes no difference to those > existed encoding, length calculation code. > > Meanwhile one new DWARF expression operation number is still needed for > AArch64, it's useful for describing those complex pointer signing scenarios > and it will be used to multiplex some further extensions on AArch64. > > 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 <rearnsha@arm.com> > Jiong Wang <jiong.wang@arm.com> > > * dwarf2.def (DW_OP_AARCH64_operation): Reserve the number 0xea. Ping~ Thanks. -- Regards, Jiong ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Ping^2][1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-12-12 13:40 ` [Ping~][1/9][RFC][DWARF] " Jiong Wang @ 2016-12-19 13:59 ` Jiong Wang 2016-12-28 18:21 ` [Ping^3][1/9][RFC][DWARF] " Jiong Wang 0 siblings, 1 reply; 25+ messages in thread From: Jiong Wang @ 2016-12-19 13:59 UTC (permalink / raw) To: Jakub Jelinek, Mark Wielaard Cc: Richard Earnshaw (lists), gcc-patches, gdb-patches, Binutils, Jason Merrill, ccoutant 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 +0000, 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 is expected to be used for most of the time. DW_OP_AARCH64_pauth >>>>> is designed as a generic operation that allow describing pointer signing on >>>>> any value using any salt and key in case we can't use the shortcut operations >>>>> we can use this. >>>> >>>> I admit to not fully understand the salting/keying involved. But given >>>> that the DW_OP space is really tiny, so we would like to not eat up too >>>> many of them for new opcodes. And given that introducing any new DW_OPs >>>> using for CFI unwinding will break any unwinder anyway causing us to >>>> update them all for this new feature. Have you thought about using a new >>>> CIE augmentation string character for describing that the return >>>> address/link register used by a function/frame is salted/keyed? >>>> >>>> This seems a good description of CIE records and augmentation >>>> characters:http://www.airs.com/blog/archives/460 >>>> >>>> It obviously also involves updating all unwinders to understand the new >>>> augmentation character (and possible arguments). But it might be more >>>> generic and saves us from using up too many DW_OPs. >>> >>> From what I understood, the return address is not always scrambled, so >>> it doesn't apply to the whole function, just to most of it (except for >>> an insn in the prologue and some in the epilogue). So I think one op is >>> needed. But can't it be just a toggable flag whether the return address >>> is scrambled + some arguments to it? >>> Thus DW_OP_AARCH64_scramble .uleb128 0 would mean that the default >>> way of scrambling starts here (if not already active) or any kind of >>> scrambling ends here (if already active), and >>> DW_OP_AARCH64_scramble .uleb128 non-zero would be whatever encoding you need >>> to represent details of the less common variants with details what to do. >>> Then you'd just hook through some MD_* macro in the unwinder the >>> descrambling operation if the scrambling is active at the insns you unwind >>> on. >>> >>> Jakub >> >> Hi Mark, Jakub: >> >> Thanks very much for the suggestions. >> >> I have done some experiments on your ideas and am thinking it's good to >> combine them together. The use of DW_CFA instead of DW_OP can avoid building >> all information from scratch at each unwind location, while we can indicate >> the signing key index through new AArch64 CIE augmentation 'B'. This new >> approach reduce the unwind table size overhead from ~25% to ~5% when return >> address signing enabled, it also largely simplified dwarf generation code for >> return address signing. >> >> As one new DWARF call frame instruction is needed for AArch64, I want to reuse >> DW_CFA_GNU_window_save to save the space. It is in vendor extension space and >> used for Sparc only, I think it make sense to reuse it for AArch64. On >> AArch64, DW_CFA_GNU_window_save toggle return address sign status which kept >> in a new boolean type column in DWARF table, so DW_CFA_GNU_window_save takes >> no argument on AArch64, the same as on Sparc, this makes no difference to those >> existed encoding, length calculation code. >> >> Meanwhile one new DWARF expression operation number is still needed for >> AArch64, it's useful for describing those complex pointer signing scenarios >> and it will be used to multiplex some further extensions on AArch64. >> >> 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 <rearnsha@arm.com> >> Jiong Wang <jiong.wang@arm.com> >> >> * dwarf2.def (DW_OP_AARCH64_operation): Reserve the number 0xea. > > Ping~ Ping^2 -- Regards, Jiong ^ permalink raw reply [flat|nested] 25+ messages in thread
* [Ping^3][1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-12-19 13:59 ` [Ping^2][1/9][RFC][DWARF] " Jiong Wang @ 2016-12-28 18:21 ` Jiong Wang 0 siblings, 0 replies; 25+ messages in thread From: Jiong Wang @ 2016-12-28 18:21 UTC (permalink / raw) To: Jakub Jelinek, Mark Wielaard, law Cc: Richard Earnshaw (lists), gcc-patches, gdb-patches, Binutils, Jason Merrill, ccoutant 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 +0000, 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 is expected to be used for most of the time. DW_OP_AARCH64_pauth >>>>>> is designed as a generic operation that allow describing pointer signing on >>>>>> any value using any salt and key in case we can't use the shortcut operations >>>>>> we can use this. >>>>> >>>>> I admit to not fully understand the salting/keying involved. But given >>>>> that the DW_OP space is really tiny, so we would like to not eat up too >>>>> many of them for new opcodes. And given that introducing any new DW_OPs >>>>> using for CFI unwinding will break any unwinder anyway causing us to >>>>> update them all for this new feature. Have you thought about using a new >>>>> CIE augmentation string character for describing that the return >>>>> address/link register used by a function/frame is salted/keyed? >>>>> >>>>> This seems a good description of CIE records and augmentation >>>>> characters:http://www.airs.com/blog/archives/460 >>>>> >>>>> It obviously also involves updating all unwinders to understand the new >>>>> augmentation character (and possible arguments). But it might be more >>>>> generic and saves us from using up too many DW_OPs. >>>> >>>> From what I understood, the return address is not always scrambled, so >>>> it doesn't apply to the whole function, just to most of it (except for >>>> an insn in the prologue and some in the epilogue). So I think one op is >>>> needed. But can't it be just a toggable flag whether the return address >>>> is scrambled + some arguments to it? >>>> Thus DW_OP_AARCH64_scramble .uleb128 0 would mean that the default >>>> way of scrambling starts here (if not already active) or any kind of >>>> scrambling ends here (if already active), and >>>> DW_OP_AARCH64_scramble .uleb128 non-zero would be whatever encoding you need >>>> to represent details of the less common variants with details what to do. >>>> Then you'd just hook through some MD_* macro in the unwinder the >>>> descrambling operation if the scrambling is active at the insns you unwind >>>> on. >>>> >>>> Jakub >>> >>> Hi Mark, Jakub: >>> >>> Thanks very much for the suggestions. >>> >>> I have done some experiments on your ideas and am thinking it's good to >>> combine them together. The use of DW_CFA instead of DW_OP can avoid building >>> all information from scratch at each unwind location, while we can indicate >>> the signing key index through new AArch64 CIE augmentation 'B'. This new >>> approach reduce the unwind table size overhead from ~25% to ~5% when return >>> address signing enabled, it also largely simplified dwarf generation code for >>> return address signing. >>> >>> As one new DWARF call frame instruction is needed for AArch64, I want to reuse >>> DW_CFA_GNU_window_save to save the space. It is in vendor extension space and >>> used for Sparc only, I think it make sense to reuse it for AArch64. On >>> AArch64, DW_CFA_GNU_window_save toggle return address sign status which kept >>> in a new boolean type column in DWARF table, so DW_CFA_GNU_window_save takes >>> no argument on AArch64, the same as on Sparc, this makes no difference to those >>> existed encoding, length calculation code. >>> >>> Meanwhile one new DWARF expression operation number is still needed for >>> AArch64, it's useful for describing those complex pointer signing scenarios >>> and it will be used to multiplex some further extensions on AArch64. >>> >>> 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 <rearnsha@arm.com> >>> Jiong Wang <jiong.wang@arm.com> >>> >>> * dwarf2.def (DW_OP_AARCH64_operation): Reserve the number 0xea. >> >> Ping~ > Ping^2 Ping^3 Can DWARF maintainers or global reviewers have a look at this? Thanks very much. -- Regards, Jiong ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-11-30 11:15 ` Jiong Wang 2016-11-30 18:25 ` Yao Qi 2016-12-12 13:40 ` [Ping~][1/9][RFC][DWARF] " Jiong Wang @ 2016-12-28 19:54 ` Cary Coutant 2017-01-03 9:32 ` Jiong Wang 2017-01-03 10:10 ` Jiong Wang 2 siblings, 2 replies; 25+ messages in thread From: Cary Coutant @ 2016-12-28 19:54 UTC (permalink / raw) To: Jiong Wang Cc: Jakub Jelinek, Mark Wielaard, Richard Earnshaw (lists), gcc-patches, GDB, Binutils > 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 <rearnsha@arm.com> > Jiong Wang <jiong.wang@arm.com> > > * dwarf2.def (DW_OP_AARCH64_operation): Reserve the number 0xea. This is OK, but: +/* AARCH64 extensions. + DW_OP_AARCH64_operation takes one mandatory unsigned LEB128 operand. + Bits[6:0] of this operand is the action code, all others bits are initialized + to 0 except explicitly documented for one action. Please refer AArch64 DWARF + ABI documentation for details. */ Is it possible to include a stable URL that points to the ABI document? -cary ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-12-28 19:54 ` [1/9][RFC][DWARF] " Cary Coutant @ 2017-01-03 9:32 ` Jiong Wang 2017-01-03 10:10 ` Jiong Wang 1 sibling, 0 replies; 25+ messages in thread From: Jiong Wang @ 2017-01-03 9:32 UTC (permalink / raw) To: Cary Coutant Cc: Jakub Jelinek, Mark Wielaard, Richard Earnshaw (lists), gcc-patches, GDB, Binutils 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 <rearnsha@arm.com> >> Jiong Wang <jiong.wang@arm.com> >> >> * dwarf2.def (DW_OP_AARCH64_operation): Reserve the number 0xea. > This is OK, but: > > +/* AARCH64 extensions. > + DW_OP_AARCH64_operation takes one mandatory unsigned LEB128 operand. > + Bits[6:0] of this operand is the action code, all others bits are > initialized > + to 0 except explicitly documented for one action. Please refer > AArch64 DWARF > + ABI documentation for details. */ > > Is it possible to include a stable URL that points to the ABI document? Hi Cary, Thanks for the review. Currently there is no URL for this AArch64 DWARF ABI updates. I will update the comments as soon as the stable URL is available. Regards, Jiong ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-12-28 19:54 ` [1/9][RFC][DWARF] " Cary Coutant 2017-01-03 9:32 ` Jiong Wang @ 2017-01-03 10:10 ` Jiong Wang 2017-01-03 10:57 ` Yao Qi 1 sibling, 1 reply; 25+ messages in thread From: Jiong Wang @ 2017-01-03 10:10 UTC (permalink / raw) To: GDB, Binutils; +Cc: Richard Earnshaw (lists), Nick Clifton 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 <rearnsha@arm.com> >> Jiong Wang <jiong.wang@arm.com> >> >> * dwarf2.def (DW_OP_AARCH64_operation): Reserve the number 0xea. > This is OK, but: > > +/* AARCH64 extensions. > + DW_OP_AARCH64_operation takes one mandatory unsigned LEB128 operand. > + Bits[6:0] of this operand is the action code, all others bits are > initialized > + to 0 except explicitly documented for one action. Please refer > AArch64 DWARF > + ABI documentation for details. */ > > Is it possible to include a stable URL that points to the ABI document? > > -cary As this patch has got approve from GCC, is it OK to install into binutils-gdb master? My understanding is "include/dwarf2.def" is shared between GDB and Binutils. This patch and the described AArch64 DWARF proposal has got GDB ack from https://sourceware.org/ml/gdb-patches/2016-11/msg01008.html which, from my understanding, is a conditional approval given there is follow up GDB patches on multiplexing DW_CFA_GNU_window_save. This patch still need Binutils approval. Thanks. Regards, Jiong ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2017-01-03 10:10 ` Jiong Wang @ 2017-01-03 10:57 ` Yao Qi 2017-01-03 15:21 ` Nick Clifton 0 siblings, 1 reply; 25+ messages in thread From: Yao Qi @ 2017-01-03 10:57 UTC (permalink / raw) To: Jiong Wang; +Cc: GDB, Binutils, Richard Earnshaw (lists), Nick Clifton On Tue, Jan 3, 2017 at 10:09 AM, Jiong Wang <jiong.wang@foss.arm.com> wrote: > 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 <rearnsha@arm.com> >>> Jiong Wang <jiong.wang@arm.com> >>> >>> * dwarf2.def (DW_OP_AARCH64_operation): Reserve the number 0xea. >> >> This is OK, but: >> >> +/* AARCH64 extensions. >> + DW_OP_AARCH64_operation takes one mandatory unsigned LEB128 operand. >> + Bits[6:0] of this operand is the action code, all others bits are >> initialized >> + to 0 except explicitly documented for one action. Please refer >> AArch64 DWARF >> + ABI documentation for details. */ >> >> Is it possible to include a stable URL that points to the ABI document? >> >> -cary > > > As this patch has got approve from GCC, is it OK to install into > binutils-gdb master? > > My understanding is "include/dwarf2.def" is shared between GDB and > Binutils. "include/dwarf2.def" in binutils-gdb is a copy from gcc, as the comments in the top explain "This file is part of GCC.". Since the patch was approved in GCC, you need to commit the patch to GCC repository, and sync "include/dwarf2.def" from GCC repo to binutils-gdb repo. The last sync is done by Nick https://sourceware.org/ml/binutils/2015-09/msg00330.html > > This patch and the described AArch64 DWARF proposal has got GDB ack from > https://sourceware.org/ml/gdb-patches/2016-11/msg01008.html which, from my > understanding, is a conditional approval given there is follow up GDB > patches on multiplexing DW_CFA_GNU_window_save. > > This patch still need Binutils approval. > The sync is regarded as an obvious change, so you can commit it in binutils-gdb repo. -- Yao (齐尧) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2017-01-03 10:57 ` Yao Qi @ 2017-01-03 15:21 ` Nick Clifton 2017-01-03 17:47 ` Yao Qi 0 siblings, 1 reply; 25+ messages in thread From: Nick Clifton @ 2017-01-03 15:21 UTC (permalink / raw) To: Yao Qi, Jiong Wang; +Cc: GDB, Binutils, Richard Earnshaw (lists) Hi Guys, >> As this patch has got approve from GCC, is it OK to install into >> binutils-gdb master? >> >> My understanding is "include/dwarf2.def" is shared between GDB and >> Binutils. > > "include/dwarf2.def" in binutils-gdb is a copy from gcc, as the comments in > the top explain "This file is part of GCC.". Since the patch was approved in > GCC, you need to commit the patch to GCC repository, and sync > "include/dwarf2.def" from GCC repo to binutils-gdb repo. The last sync > is done by Nick https://sourceware.org/ml/binutils/2015-09/msg00330.html I have now sync'ed the binutils copy with the current master copy in the gcc repository. Jiong - if you want to apply your patch to both the gcc and binutils repository, then this is OK with me. Cheers Nick ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2017-01-03 15:21 ` Nick Clifton @ 2017-01-03 17:47 ` Yao Qi 0 siblings, 0 replies; 25+ messages in thread From: Yao Qi @ 2017-01-03 17:47 UTC (permalink / raw) To: Nick Clifton; +Cc: Jiong Wang, GDB, Binutils, Richard Earnshaw (lists) On Tue, Jan 3, 2017 at 3:21 PM, Nick Clifton <nickc@redhat.com> wrote: > I have now sync'ed the binutils copy with the current master copy in the gcc > repository. Thanks for doing this, Nick. -- Yao (齐尧) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-11-16 14:02 ` Jakub Jelinek 2016-11-30 11:15 ` Jiong Wang @ 2016-11-30 21:44 ` Cary Coutant 2016-12-01 10:42 ` Richard Earnshaw (lists) 1 sibling, 1 reply; 25+ messages in thread From: Cary Coutant @ 2016-11-30 21:44 UTC (permalink / raw) To: Jakub Jelinek Cc: Mark Wielaard, Jiong Wang, Richard Earnshaw (lists), gcc-patches, GDB, Binutils 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 the rule for LR instead and expect an unmangled return address. The earlier example would become (picking an arbitrary value of 120 for the new virtual register number): .cfi_startproc 0x0 paciasp (this instruction sign return address register LR/X30) .cfi_val 120, DW_OP_reg30 0x4 stp x29, x30, [sp, -32]! .cfi_offset 120, -16 .cfi_offset 29, -32 .cfi_def_cfa_offset 32 0x8 add x29, sp, 0 Just a suggestion... -cary On Wed, Nov 16, 2016 at 6:02 AM, Jakub Jelinek <jakub@redhat.com> wrote: > On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote: >> On Wed, 2016-11-16 at 10:00 +0000, 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 is expected to be used for most of the time. DW_OP_AARCH64_pauth >> > is designed as a generic operation that allow describing pointer signing on >> > any value using any salt and key in case we can't use the shortcut operations >> > we can use this. >> >> I admit to not fully understand the salting/keying involved. But given >> that the DW_OP space is really tiny, so we would like to not eat up too >> many of them for new opcodes. And given that introducing any new DW_OPs >> using for CFI unwinding will break any unwinder anyway causing us to >> update them all for this new feature. Have you thought about using a new >> CIE augmentation string character for describing that the return >> address/link register used by a function/frame is salted/keyed? >> >> This seems a good description of CIE records and augmentation >> characters: http://www.airs.com/blog/archives/460 >> >> It obviously also involves updating all unwinders to understand the new >> augmentation character (and possible arguments). But it might be more >> generic and saves us from using up too many DW_OPs. > > From what I understood, the return address is not always scrambled, so > it doesn't apply to the whole function, just to most of it (except for > an insn in the prologue and some in the epilogue). So I think one op is > needed. But can't it be just a toggable flag whether the return address > is scrambled + some arguments to it? > Thus DW_OP_AARCH64_scramble .uleb128 0 would mean that the default > way of scrambling starts here (if not already active) or any kind of > scrambling ends here (if already active), and > DW_OP_AARCH64_scramble .uleb128 non-zero would be whatever encoding you need > to represent details of the less common variants with details what to do. > Then you'd just hook through some MD_* macro in the unwinder the > descrambling operation if the scrambling is active at the insns you unwind > on. > > Jakub ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-11-30 21:44 ` Cary Coutant @ 2016-12-01 10:42 ` Richard Earnshaw (lists) 2016-12-01 11:09 ` Jiong Wang 0 siblings, 1 reply; 25+ messages in thread From: Richard Earnshaw (lists) @ 2016-12-01 10:42 UTC (permalink / raw) To: Cary Coutant, Jakub Jelinek Cc: Mark Wielaard, Jiong Wang, gcc-patches, GDB, Binutils 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 address using that rule; > otherwise, you would use the rule for LR instead and expect an > unmangled return address. The earlier example would become (picking an > arbitrary value of 120 for the new virtual register number): > > .cfi_startproc > 0x0 paciasp (this instruction sign return address register LR/X30) > .cfi_val 120, DW_OP_reg30 > 0x4 stp x29, x30, [sp, -32]! > .cfi_offset 120, -16 > .cfi_offset 29, -32 > .cfi_def_cfa_offset 32 > 0x8 add x29, sp, 0 > > Just a suggestion... What about signing other registers? And what if the value is then copied to another register? Don't you end up with every possible register (including the FP/SIMD registers) needing a shadow copy? R. > > -cary > > > On Wed, Nov 16, 2016 at 6:02 AM, Jakub Jelinek <jakub@redhat.com> wrote: >> On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote: >>> On Wed, 2016-11-16 at 10:00 +0000, 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 is expected to be used for most of the time. DW_OP_AARCH64_pauth >>>> is designed as a generic operation that allow describing pointer signing on >>>> any value using any salt and key in case we can't use the shortcut operations >>>> we can use this. >>> >>> I admit to not fully understand the salting/keying involved. But given >>> that the DW_OP space is really tiny, so we would like to not eat up too >>> many of them for new opcodes. And given that introducing any new DW_OPs >>> using for CFI unwinding will break any unwinder anyway causing us to >>> update them all for this new feature. Have you thought about using a new >>> CIE augmentation string character for describing that the return >>> address/link register used by a function/frame is salted/keyed? >>> >>> This seems a good description of CIE records and augmentation >>> characters: http://www.airs.com/blog/archives/460 >>> >>> It obviously also involves updating all unwinders to understand the new >>> augmentation character (and possible arguments). But it might be more >>> generic and saves us from using up too many DW_OPs. >> >> From what I understood, the return address is not always scrambled, so >> it doesn't apply to the whole function, just to most of it (except for >> an insn in the prologue and some in the epilogue). So I think one op is >> needed. But can't it be just a toggable flag whether the return address >> is scrambled + some arguments to it? >> Thus DW_OP_AARCH64_scramble .uleb128 0 would mean that the default >> way of scrambling starts here (if not already active) or any kind of >> scrambling ends here (if already active), and >> DW_OP_AARCH64_scramble .uleb128 non-zero would be whatever encoding you need >> to represent details of the less common variants with details what to do. >> Then you'd just hook through some MD_* macro in the unwinder the >> descrambling operation if the scrambling is active at the insns you unwind >> on. >> >> Jakub ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-12-01 10:42 ` Richard Earnshaw (lists) @ 2016-12-01 11:09 ` Jiong Wang 0 siblings, 0 replies; 25+ messages in thread From: Jiong Wang @ 2016-12-01 11:09 UTC (permalink / raw) To: Richard Earnshaw (lists), Cary Coutant, Jakub Jelinek Cc: Mark Wielaard, gcc-patches, GDB, Binutils 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, >> you'd expect to find the mangled return address using that rule; >> otherwise, you would use the rule for LR instead and expect an >> unmangled return address. The earlier example would become (picking an >> arbitrary value of 120 for the new virtual register number): >> >> .cfi_startproc >> 0x0 paciasp (this instruction sign return address register LR/X30) >> .cfi_val 120, DW_OP_reg30 >> 0x4 stp x29, x30, [sp, -32]! >> .cfi_offset 120, -16 >> .cfi_offset 29, -32 >> .cfi_def_cfa_offset 32 >> 0x8 add x29, sp, 0 >> >> Just a suggestion... > What about signing other registers? And what if the value is then > copied to another register? Don't you end up with every possible > register (including the FP/SIMD registers) needing a shadow copy? Another issue is compared with the DW_CFA approach, this virtual register approach is less efficient on unwind table size and complexer to implement. .cfi_register takes two ULEB128 register number, it needs 3 bytes rather than DW_CFA's 1 byte. From example .debug_frame section size for linux kernel increment will be ~14% compared with DW_CFA approach's 5%. In the implementation, the prologue then normally will be .cfi_startproc 0x0 paciasp (this instruction sign return address register LR/X30) .cfi_val 120, DW_OP_reg30 <-A 0x4 stp x29, x30, [sp, -32]! .cfi_offset 120, -16 <-B .cfi_offset 29, -32 .cfi_def_cfa_offset 32 The epilogue normally will be ... ldp x29, x30, [sp], 32 .cfi_val 120, DW_OP_reg30 <- C .cfi_restore 29 .cfi_def_cfa 31, 0 autiasp (this instruction unsign LR/X30) .cfi_restore 30 For the virual register approach, GCC needs to track dwarf generation for LR/X30 in every place (A/B/C, maybe some other rare LR copy places), and rewrite LR to new virtual register accordingly. This seems easy, but my practice shows GCC won't do any DWARF auto-deduction if you have one explict DWARF CFI note attached to an insn (handled_one will be true in dwarf2out_frame_debug). So for instruction like stp/ldp, we then need to explicitly generate all three DWARF CFI note manually. While for DW_CFA approach, they will be: .cfi_startproc 0x0 paciasp (this instruction sign return address register LR/X30) .cfi_cfa_window_save 0x4 stp x29, x30, [sp, -32]! \ .cfi_offset 30, -16 | .cfi_offset 29, -32 | .cfi_def_cfa_offset 32 | all dwarf generation between sign and ... | unsign (paciasp/autiasp) is the same ldp x29, x30, [sp], 16 | as before .cfi_restore 30 | .cfi_restore 29 | .cfi_def_cfa 31, 0 | / autiasp (this instruction unsign LR/X30) .cfi_cfa_window_save The DWARF generation implementation in backend is very simple, nothing needs to be updated between sign and unsign instruction. For the impact on the unwinder, the virtual register approach needs to change the implementation of "save value" rule which is quite general code. A target hook might need for AArch64 that when the destination register is the special virtual register, it seems a little bit hack to me. >> -cary >> >> >> On Wed, Nov 16, 2016 at 6:02 AM, Jakub Jelinek <jakub@redhat.com> wrote: >>> On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote: >>>> On Wed, 2016-11-16 at 10:00 +0000, 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 is expected to be used for most of the time. DW_OP_AARCH64_pauth >>>>> is designed as a generic operation that allow describing pointer signing on >>>>> any value using any salt and key in case we can't use the shortcut operations >>>>> we can use this. >>>> I admit to not fully understand the salting/keying involved. But given >>>> that the DW_OP space is really tiny, so we would like to not eat up too >>>> many of them for new opcodes. And given that introducing any new DW_OPs >>>> using for CFI unwinding will break any unwinder anyway causing us to >>>> update them all for this new feature. Have you thought about using a new >>>> CIE augmentation string character for describing that the return >>>> address/link register used by a function/frame is salted/keyed? >>>> >>>> This seems a good description of CIE records and augmentation >>>> characters: http://www.airs.com/blog/archives/460 >>>> >>>> It obviously also involves updating all unwinders to understand the new >>>> augmentation character (and possible arguments). But it might be more >>>> generic and saves us from using up too many DW_OPs. >>> From what I understood, the return address is not always scrambled, so >>> it doesn't apply to the whole function, just to most of it (except for >>> an insn in the prologue and some in the epilogue). So I think one op is >>> needed. But can't it be just a toggable flag whether the return address >>> is scrambled + some arguments to it? >>> Thus DW_OP_AARCH64_scramble .uleb128 0 would mean that the default >>> way of scrambling starts here (if not already active) or any kind of >>> scrambling ends here (if already active), and >>> DW_OP_AARCH64_scramble .uleb128 non-zero would be whatever encoding you need >>> to represent details of the less common variants with details what to do. >>> Then you'd just hook through some MD_* macro in the unwinder the >>> descrambling operation if the scrambling is active at the insns you unwind >>> on. >>> >>> Jakub ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-11-15 16:18 ` Jakub Jelinek 2016-11-15 16:48 ` Jiong Wang @ 2016-11-15 16:51 ` Jiong Wang 1 sibling, 0 replies; 25+ messages in thread From: Jiong Wang @ 2016-11-15 16:51 UTC (permalink / raw) To: Jakub Jelinek, mjw Cc: gcc-patches, gdb-patches, Binutils, Richard Earnshaw (lists) On 15/11/16 16:18, Jakub Jelinek wrote: > On Tue, Nov 15, 2016 at 04:00:40PM +0000, 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 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. >> Seperate DWARF operations are introduced instead of combining all of them into >> one are mostly because these operations are going to be used for most of the >> functions once return address signing are enabled, and they are used for >> describing frame unwinding that they will go into unwind table for C++ program >> or C program compiled with -fexceptions, the impact on unwind table size is >> significant. So I was trying to lower the unwind table size overhead as much as >> I can. >> >> IMHO, three numbers actually is not that much for one architecture in DWARF >> operation vendor extension space as vendors can overlap with each other. The >> only painful thing from my understand is there are platform vendors, for example >> "GNU" and "LLVM" etc, for which architecture vendor can't overlap with. > For DW_OP_*, there aren't two vendor ranges like e.g. in ELF, there is just > one range, so ideally the opcodes would be unique everywhere, if not, there > is just a single GNU vendor, there is no separate range for Aarch64, that > can overlap with range for x86_64, and powerpc, etc. > > Perhaps we could declare that certain opcode subrange for the GNU vendor is > architecture specific and document that the meaning of opcodes in that range > and count/encoding of their arguments depends on the architecture, but then > we should document how to figure out the architecture too (e.g. for ELF > base it on the containing EM_*). All the tools that look at DWARF (readelf, > objdump, eu-readelf, libdw, libunwind, gdb, dwz, ...) would need to agree on that > though. > > 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 frequently and at different pcs? I think it's the latter, the DW_OP_AARCH64_paciasp and DW_OP_AARCH64_paciasp_deref are going to appear frequently and at different pcs. For example, the following function prologue, there are three instructions at 0x0, 0x4, 0x8. After the first instruction at 0x0, LR/X30 will be mangled. The "paciasp" always mangle LR register using SP as salt and write back the value into LR. We then generate DW_OP_AARCH64_paciasp to notify any unwinder that the original LR is mangled in this way so they can unwind the original value properly. After the second instruction at 0x4, The mangled value of LR/X30 will be pushed on to stack, unlike usual .cfi_offset, the unwind rule for LR/X30 becomes: first fetch the mangled value from stack offset -16, then do whatever to restore the original value from the mangled value. This is represented by (DW_OP_AARCH64_paciasp_deref, offset). .cfi_startproc 0x0 paciasp (this instruction sign return address register LR/X30) .cfi_val_expression 30, DW_OP_AARCH64_paciasp 0x4 stp x29, x30, [sp, -32]! .cfi_val_expression 30, DW_OP_AARCH64_paciasp_deref, -16 .cfi_offset 29, -32 .cfi_def_cfa_offset 32 0x8 add x29, sp, 0 > Perhaps if there is just 1 > opcode and has all the info encoded just in one bigger uleb128 or something > similar... > > Jakub ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space 2016-11-11 19:39 ` Jakub Jelinek 2016-11-15 16:00 ` Jiong Wang @ 2016-12-28 19:48 ` Cary Coutant 1 sibling, 0 replies; 25+ messages in thread From: Cary Coutant @ 2016-12-28 19:48 UTC (permalink / raw) To: Jakub Jelinek Cc: Jiong Wang, gcc-patches, GDB, Binutils, Richard Earnshaw (lists) > 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. Most of the Gnu extensions have been adopted into the standard as of DWARF 5: /* GNU extensions. */ DW_OP (DW_OP_GNU_push_tls_address, 0xe0) /* The following is for marking variables that are uninitialized. */ DW_OP (DW_OP_GNU_uninit, 0xf0) DW_OP (DW_OP_GNU_encoded_addr, 0xf1) /* The GNU implicit pointer extension. See http://www.dwarfstd.org/ShowIssue.php?issue=100831.1&type=open . */ DW_OP (DW_OP_GNU_implicit_pointer, 0xf2) /* The GNU entry value extension. See http://www.dwarfstd.org/ShowIssue.php?issue=100909.1&type=open . */ DW_OP (DW_OP_GNU_entry_value, 0xf3) /* The GNU typed stack extension. See http://www.dwarfstd.org/doc/040408.1.html . */ DW_OP (DW_OP_GNU_const_type, 0xf4) DW_OP (DW_OP_GNU_regval_type, 0xf5) DW_OP (DW_OP_GNU_deref_type, 0xf6) DW_OP (DW_OP_GNU_convert, 0xf7) DW_OP (DW_OP_GNU_reinterpret, 0xf9) /* The GNU parameter ref extension. */ DW_OP (DW_OP_GNU_parameter_ref, 0xfa) /* Extensions for Fission. See http://gcc.gnu.org/wiki/DebugFission. */ DW_OP (DW_OP_GNU_addr_index, 0xfb) DW_OP (DW_OP_GNU_const_index, 0xfc) Of these, I think only DW_OP_GNU_uninit and DW_OP_GNU_encoded_addr remain as Gnu extensions. The rest could be deprecated as of DWARF 5, and, if necessary, reused for other purposes in DWARF 6 and later. Depending on how aggressive we want to be with deprecation, we could even declare that they are available for reuse in DWARF 5 and later, as long as the Gnu toolchain uses only the new standard values when generating DWARF 5. That frees up 11 more opcodes. -cary ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2017-01-03 17:47 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <c9da17a6-c3de-4466-c023-4e4ddbe38efb@foss.arm.com> 2016-11-11 18:22 ` [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space Jiong Wang 2016-11-11 19:39 ` Jakub Jelinek 2016-11-15 16:00 ` Jiong Wang 2016-11-15 16:18 ` Jakub Jelinek 2016-11-15 16:48 ` Jiong Wang 2016-11-15 19:25 ` Richard Earnshaw (lists) 2016-11-16 10:00 ` Jiong Wang 2016-11-16 13:55 ` Mark Wielaard 2016-11-16 14:02 ` Jakub Jelinek 2016-11-30 11:15 ` Jiong Wang 2016-11-30 18:25 ` Yao Qi 2016-12-12 13:40 ` [Ping~][1/9][RFC][DWARF] " Jiong Wang 2016-12-19 13:59 ` [Ping^2][1/9][RFC][DWARF] " Jiong Wang 2016-12-28 18:21 ` [Ping^3][1/9][RFC][DWARF] " Jiong Wang 2016-12-28 19:54 ` [1/9][RFC][DWARF] " Cary Coutant 2017-01-03 9:32 ` Jiong Wang 2017-01-03 10:10 ` Jiong Wang 2017-01-03 10:57 ` Yao Qi 2017-01-03 15:21 ` Nick Clifton 2017-01-03 17:47 ` Yao Qi 2016-11-30 21:44 ` Cary Coutant 2016-12-01 10:42 ` Richard Earnshaw (lists) 2016-12-01 11:09 ` Jiong Wang 2016-11-15 16:51 ` Jiong Wang 2016-12-28 19:48 ` Cary Coutant
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).