[committed] MAINTAINERS: Update my email address

cmuellner Steven Munroe munroesj Philippe De Muyter - Joseph Myersjsm28 -Szabolcs Nagy nsz +Szabolcs Nagy nsz Victor Do Nascimento

[PATCH] aarch64: libgcc: Cleanup ELF marking in asm

Use aarch64-asm.h in asm code consistently, this was started in commit c608ada288ced0268c1fd4136f56c34b24d4 Author: Zac Walker CommitDate: 2024-01-23 15:32:30 + Ifdef `.hidden`, `.type`, and `.size` pseudo-ops for `aarch64-w64-mingw32` target But that commit failed to remov

Re: [RFC] Either fix or disable SME feature for `aarch64-w64-mingw32` target?

this patch added double notes on crt*.o and lse derived objects. (which does not seem to cause build break but some linkers may not like it) after #include "aarch64-asm.h" all gnu-stack and gnu-property related stuff should be removed since the header takes care of it.

Re: [RFC] Either fix or disable SME feature for `aarch64-w64-mingw32` target?

The 01/15/2024 17:21, Radek Barton wrote: v4-0001-Ifdef-.hidden-.type-and-.size-pseudo-ops-for-aarc.patch Description: v4-0001-Ifdef-.hidden-.type-and-.size-pseudo-ops-for-aarc.patch

[PATCH v2] aarch64: Fix eh_return for -mtrack-speculation [PR112987]

Recent commit introduced a conditional branch in eh_return epilogues that is not compatible with speculation tracking: commit 426fddcbdad6746fe70e031f707fb07f55dfb405 Author: Szabolcs Nagy CommitDate: 2023-11-27 15:52:48 + aarch64: Use br instead of ret for eh_return Refactor

[PATCH] aarch64: Fix eh_return for -mtrack-speculation [PR112987]

Recent commit introduced a conditional branch in eh_return epilogues that is not compatible with speculation tracking: commit 426fddcbdad6746fe70e031f707fb07f55dfb405 Author: Szabolcs Nagy CommitDate: 2023-11-27 15:52:48 + aarch64: Use br instead of ret for eh_return gcc

Re: [PATCH v2 7/7] aarch64,arm: Move branch-protection data to targets

The 12/07/2023 13:13, Richard Earnshaw wrote: > On 03/11/2023 15:36, Szabolcs Nagy wrote: > > * config/aarch64/aarch64.cc (aarch_handle_no_branch_protection): Copy. > > (aarch_handle_standard_branch_protection): Copy. > > (aarch_handle_pac_

[PATCH v4] aarch64,arm: Move branch-protection data to targets

The branch-protection types are target specific, not the same on arm and aarch64. This currently affects pac-ret+b-key, but there will be a new type on aarch64 that is not relevant for arm. After the move, change aarch_ identifiers to aarch64_ or arm_ as appropriate. Refactor aarch_validate_mbra

[PATCH] aarch64: fortran: Adjust vect-8.f90 for libmvec

With new glibc one more loop can be vectorized via simd exp in libmvec. Found by the Linaro TCWG CI. gcc/testsuite/ChangeLog: * gfortran/vect/vect-8.f90: Accept more vectorized loops. --- gcc/testsuite/gfortran.dg/vect/vect-8.f90 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH v3] aarch64,arm: Move branch-protection data to targets

The branch-protection types are target specific, not the same on arm and aarch64. This currently affects pac-ret+b-key, but there will be a new type on aarch64 that is not relevant for arm. After the move, change aarch_ identifiers to aarch64_ or arm_ as appropriate. gcc/ChangeLog: * co

Re: [PATCH] libatomic: Add rcpc3 128-bit atomic operations for AArch64

The 11/13/2023 11:47, Victor Do Nascimento wrote: > +/* LRCPC atomic support encoded in ID_AA64ISAR1_EL1.Atomic, > + bits[23:20]. The expected value is 0b0011. Check that. */ > +#define HAS_LRCPC3() ({ \ > + unsigned long val;

Re: [PATCH v2 2/2] libatomic: Enable LSE128 128-bit atomics for armv9.4-a

The 11/29/2023 15:15, Richard Earnshaw wrote: > On 13/11/2023 11:37, Victor Do Nascimento wrote: > > +/* LSE128 atomic support encoded in ID_AA64ISAR0_EL1.Atomic, > > + bits[23:20]. The expected value is 0b0011. Check that. */ > > +#define HAS_LSE128() ({

[committed] libgcc: Fix config.in

It was updated incorrectly in commit dbbfb52b0e9c66ee9d05b8fd17c4f44655e48463 Author: Szabolcs Nagy CommitDate: 2023-12-08 11:29:06 + libgcc: aarch64: Configure check for __getauxval so regenerate it. libgcc/ChangeLog: * config.in: Regenerate. --- libgcc/config.in

[PATCH v2] libgcc: aarch64: Add SME runtime support

The call ABI for SME (Scalable Matrix Extension) requires a number of helper routines which are added to libgcc so they are tied to the compiler version instead of the libc version. See https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#sme-support-routines The routines are in sh

Re: [PATCH 3/4] libgcc: aarch64: Add SME runtime support

The 12/07/2023 17:36, Richard Sandiford wrote: > Szabolcs Nagy writes: > > + > > +#include "auto-target.h" > > +#include > > + sorry, this seems to fail when building --without-headers i will respin this, handling the 'inhibit_libc' case.

[PATCH 4/4] libgcc: aarch64: Add SME unwinder support

To support the ZA lazy save scheme, the PCS requires the unwinder to reset the SME state to PSTATE.SM=0, PSTATE.ZA=0, TPIDR2_EL0=0 on entry to an exception handler. We use the __arm_za_disable SME runtime call unconditionally to achieve this. https://github.com/ARM-software/abi-aa/blob/main/aapcs64

[PATCH 3/4] libgcc: aarch64: Add SME runtime support

The call ABI for SME (Scalable Matrix Extension) requires a number of helper routines which are added to libgcc so they are tied to the compiler version instead of the libc version. See https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#sme-support-routines The routines are in sh

[PATCH 2/4] libgcc: aarch64: Configure check for __getauxval

Add configure check for the __getauxval ABI symbol, which is always available on aarch64 glibc, and may be available on other linux C runtimes. For now only enabled on glibc, others have to override it target_configargs=libgcc_cv_have___getauxval=yes This is deliberately obscure as it should be

[PATCH 1/4] libgcc: aarch64: Configure check for .variant_pcs support

Ideally SME support routines in libgcc are marked as variant PCS symbols so check if as supports the directive. --- libgcc/config.in| 3 +++ libgcc/configure| 39 +++ libgcc/configure.ac | 17 + 3 files changed, 59 insertions(+) diff --

[PATCH 0/4] libgcc: aarch64: Add SME runtime

Add SME (Scalable Matrix Extension) support to libgcc. Szabolcs Nagy (4): libgcc: aarch64: Configure check for .variant_pcs support libgcc: aarch64: Configure check for __getauxval libgcc: aarch64: Add SME runtime support libgcc: aarch64: Add SME unwinder support libgcc/config.in

[PATCH] aarch64: fix eh_return-3.c test

gcc/testsuite/ChangeLog: * gcc.target/aarch64/eh_return-3.c: Fix when retaa is available. --- gcc/testsuite/gcc.target/aarch64/eh_return-3.c | 4 1 file changed, 4 insertions(+) diff --git a/gcc/testsuite/gcc.target/aarch64/eh_return-3.c b/gcc/testsuite/gcc.target/aarch64/eh_return

Re: [PATCH] aarch64: Avoid -Wincompatible-pointer-types warning in Linux unwinder

The 11/10/2023 19:48, Florian Weimer wrote: > * config/aarch64/linux-unwind.h > (aarch64_fallback_frame_state): Add cast to the expected type > in sc assignment. > > (Almost a v2, but the other issue was already fixed via in r14-4183.) > > --- > libgcc/config/aarch64/linux-unwi

Re: [PATCH] aarch64: Call named function in gcc.target/aarch64/aapcs64/ice_1.c

The 11/10/2023 12:22, Florian Weimer wrote: > This test looks like it intends to pass a small struct argument > through both a non-variadic and variadic argument, but due to > the typo, it does not achieve that. > > gcc/testsuite/ > > * gcc.target/aarch64/aapcs64/ice_1.c (foo): Call named.

Re: [PATCH v2 3/7] aarch64: Add eh_return compile tests

The 11/26/2023 14:37, Richard Sandiford wrote: > Szabolcs Nagy writes: > > +++ b/gcc/testsuite/gcc.target/aarch64/eh_return-3.c > > @@ -0,0 +1,30 @@ > > +/* { dg-do compile } */ > > +/* { dg-options "-O2 -mbranch-protection=pac-ret+leaf" } */ > > Pr

Re: [PATCH v2 3/7] aarch64: Add eh_return compile tests

The 11/26/2023 14:37, Richard Sandiford wrote: > Szabolcs Nagy writes: > > +++ b/gcc/testsuite/gcc.target/aarch64/eh_return-3.c > > @@ -0,0 +1,30 @@ > > +/* { dg-do compile } */ > > +/* { dg-options "-O2 -mbranch-protection=pac-ret+leaf" } */ > > Pr

Re: [PATCH v2 1/7] aarch64: Use br instead of ret for eh_return

The 11/13/2023 01:27, Hans-Peter Nilsson wrote: > > From: Szabolcs Nagy > > Date: Fri, 3 Nov 2023 15:36:08 + > > I don't see others commenting on this patch, and you're not > mentioning this aspect, so I wonder: > > > * config/aarch64

[PATCH v2 7/7] aarch64,arm: Move branch-protection data to targets

The branch-protection types are target specific, not the same on arm and aarch64. This currently affects pac-ret+b-key, but there will be a new type on aarch64 that is not relevant for arm. gcc/ChangeLog: * config/aarch64/aarch64-opts.h (enum aarch64_key_type): Rename to ... (enu

[PATCH v2 4/7] aarch64: Disable branch-protection for pcs tests

The tests manipulate the return address in abitest-2.h and thus not compatible with -mbranch-protection=pac-ret+leaf or -mbranch-protection=gcs. gcc/testsuite/ChangeLog: * gcc.target/aarch64/aapcs64/func-ret-1.c: Disable branch-protection. * gcc.target/aarch64/aapcs64/func-ret-2.c

[PATCH v2 2/7] aarch64: Do not force a stack frame for EH returns

EH returns no longer rely on clobbering the return address on the stack so forcing a stack frame is not necessary. This does not actually change the code gen for the unwinder since there are calls before the EH return. gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_needs_frame_chain

[PATCH v2 6/7] aarch64,arm: Fix branch-protection= parsing

Refactor the parsing to have a single API and fix a few parsing issues: - Different handling of "bti+none" and "none+bti": these should be rejected because "none" can only appear alone. - Accepted empty strings such as "bti++pac-ret" or "bti+", this bug was caused by using strtok_r. - Memory

[PATCH v2 3/7] aarch64: Add eh_return compile tests

gcc/testsuite/ChangeLog: * gcc.target/aarch64/eh_return-2.c: New test. * gcc.target/aarch64/eh_return-3.c: New test. --- v2: check-function-bodies in eh_return-3.c (this is not very robust, but easier to read) --- .../gcc.target/aarch64/eh_return-2.c | 9 ++ .../gcc

[PATCH v2 5/7] aarch64,arm: Remove accepted_branch_protection_string

On aarch64 this caused ICE with pragma push_options since commit ae54c1b09963779c5c3914782324ff48af32e2f1 Author: Wilco Dijkstra CommitDate: 2022-06-01 18:13:57 +0100 AArch64: Cleanup option processing code The failure is at pop_options: internal compiler error: ‘global_options’ ar

[PATCH v2 1/7] aarch64: Use br instead of ret for eh_return

The expected way to handle eh_return is to pass the stack adjustment offset and landing pad address via EH_RETURN_STACKADJ_RTX EH_RETURN_HANDLER_RTX to the epilogue that is shared between normal return paths and the eh_return paths. EH_RETURN_HANDLER_RTX is the stack slot of the return addre

[PATCH v2 0/7] aarch64 GCS preliminary patches

.html Szabolcs Nagy (7): aarch64: Use br instead of ret for eh_return aarch64: Do not force a stack frame for EH returns aarch64: Add eh_return compile tests aarch64: Disable branch-protection for pcs tests aarch64,arm: Remove accepted_branch_protection_string aarch64,arm: Fix branch-prote

Re: [PATCH 10/11] aarch64: Fix branch-protection error message tests

The 10/13/2023 11:29, Richard Earnshaw (lists) wrote: > On 05/09/2023 16:00, Richard Sandiford via Gcc-patches wrote: > > Szabolcs Nagy writes: > >> @@ -4,19 +4,19 @@ void __attribute__ ((target("branch-protection=leaf"))) > >> foo1 () > >> { > &

[PATCH 11/11] aarch64,arm: Move branch-protection data to targets

The branch-protection types are target specific, not the same on arm and aarch64. This currently affects pac-ret+b-key, but there will be a new type on aarch64 that is not relevant for arm. gcc/ChangeLog: * config/aarch64/aarch64-opts.h (enum aarch64_key_type): Rename to ... (enu

[PATCH 05/11] aarch64: Add eh_return compile tests

gcc/testsuite/ChangeLog: * gcc.target/aarch64/eh_return-2.c: New test. * gcc.target/aarch64/eh_return-3.c: New test. --- gcc/testsuite/gcc.target/aarch64/eh_return-2.c | 9 + gcc/testsuite/gcc.target/aarch64/eh_return-3.c | 14 ++ 2 files changed, 23 insertion

[PATCH 10/11] aarch64: Fix branch-protection error message tests

Update tests for the new branch-protection parser errors. gcc/testsuite/ChangeLog: * gcc.target/aarch64/branch-protection-attr.c: Update. * gcc.target/aarch64/branch-protection-option.c: Update. --- gcc/testsuite/gcc.target/aarch64/branch-protection-attr.c | 6 +++--- gcc/tests

[PATCH 04/11] aarch64: Do not force a stack frame for EH returns

EH returns no longer rely on clobbering the return address on the stack so forcing a stack frame is not necessary. This does not actually change the code gen for the unwinder since there are calls before the EH return. gcc/ChangeLog: * config/aarch64/aarch64.cc (aarch64_needs_frame_chain

[PATCH 09/11] aarch64,arm: Fix branch-protection= parsing

Refactor the parsing to have a single API and fix a few parsing issues: - Different handling of "bti+none" and "none+bti": these should be rejected because "none" can only appear alone. - Accepted empty strings such as "bti++pac-ret" or "bti+", this bug was caused by using strtok_r. - Memory

[PATCH 02/11] Handle epilogues that contain jumps

From: Richard Sandiford The prologue/epilogue pass allows the prologue sequence to contain jumps. The sequence is then partitioned into basic blocks using find_many_sub_basic_blocks. This patch treats epilogues in the same way. It's needed for a follow-on aarch64 patch that adds conditional co

[PATCH 03/11] aarch64: Use br instead of ret for eh_return

The expected way to handle eh_return is to pass the stack adjustment offset and landing pad address via EH_RETURN_STACKADJ_RTX EH_RETURN_HANDLER_RTX to the epilogue that is shared between normal return paths and the eh_return paths. EH_RETURN_HANDLER_RTX is the stack slot of the return addre

[PATCH 08/11] aarch64,arm: Remove accepted_branch_protection_string

On aarch64 this caused ICE with pragma push_options since commit ae54c1b09963779c5c3914782324ff48af32e2f1 Author: Wilco Dijkstra CommitDate: 2022-06-01 18:13:57 +0100 AArch64: Cleanup option processing code The failure is at pop_options: internal compiler error: ‘global_options’ ar

[PATCH 07/11] aarch64: Disable branch-protection for pcs tests

The tests manipulate the return address in abitest-2.h and thus not compatible with -mbranch-protection=pac-ret+leaf or -mbranch-protection=gcs. gcc/testsuite/ChangeLog: * gcc.target/aarch64/aapcs64/func-ret-1.c: Disable branch-protection. * gcc.target/aarch64/aapcs64/func-ret-2.c

[PATCH 06/11] aarch64: Fix pac-ret eh_return tests

This is needed since eh_return no longer prevents pac-ret in the normal return path. gcc/testsuite/ChangeLog: * gcc.target/aarch64/return_address_sign_1.c: Move func4 to ... * gcc.target/aarch64/return_address_sign_2.c: ... here and fix the scan asm check. * gcc.ta

[PATCH 01/11] aarch64: AARCH64_ISA_RCPC was defined twice

gcc/ChangeLog: * config/aarch64/aarch64.h (AARCH64_ISA_RCPC): Remove dup. --- gcc/config/aarch64/aarch64.h | 1 - 1 file changed, 1 deletion(-) diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h index 2b0fc97bb71..c783cb96c48 100644 --- a/gcc/config/aarch64/aarch64.

[PATCH 00/11] aarch64 GCS preliminary patches

https://lore.kernel.org/lkml/20230807-arm64-gcs-v4-0-68cfa37f9...@kernel.org/ so it will come later. Richard Sandiford (1): Handle epilogues that contain jumps Szabolcs Nagy (10): aarch64: AARCH64_ISA_RCPC was defined twice aarch64: Use br instead of ret for eh_return aarch64: Do not force a stack frame f

Re: [PATCH] aarch64: Fix warnings during libgcc build

The 07/11/2023 17:20, Florian Weimer wrote: > * Richard Earnshaw: > > > On 11/07/2023 10:37, Florian Weimer via Gcc-patches wrote: > >> libgcc/ > >>* config/aarch64/aarch64-unwind.h > >> (aarch64_cie_signed_with_b_key): > >>Add missing const qualifier. Cast from const unsigned char * > >>

Re: [PATCH] libgcc: Fix uninitialized RA signing on AArch64 [PR107678]

The 01/03/2023 17:27, Wilco Dijkstra wrote: > > > Also, if I understood correctly, the reason we use REG_UNSAVED is to > > ensure that state from one frame isn't carried across to a parent frame, > > in cases where the parent frame lacks any signing. That is, each frame > > should start out with

Re: [PATCH] libgcc: Fix uninitialized RA signing on AArch64 [PR107678]

The 12/06/2022 11:58, Wilco Dijkstra wrote: > > i don't think how[*RA_STATE] can ever be set to REG_SAVED_OFFSET, > > this pseudo reg is not spilled to the stack, it is reset to 0 in > > each frame and then toggled within a frame. > > It's is just a state, we can use any state we want since it is

Re: [PATCH] libgcc: Fix uninitialized RA signing on AArch64 [PR107678]

The 12/05/2022 19:04, Richard Sandiford wrote: > Wilco Dijkstra writes: > > A recent change only initializes the regs.how[] during Dwarf unwinding > > which resulted in an uninitialized offset used in return address signing > > and random failures during unwinding. The fix is to use REG_SAVED_OFF

Re: [PATCH] aarch64: Fix pac-ret with unusual dwarf in libgcc unwinder [PR104689]

The 05/13/2022 16:35, Richard Sandiford wrote: > Szabolcs Nagy via Gcc-patches writes: > > The RA_SIGN_STATE dwarf pseudo-register is normally only set using the > > DW_CFA_AARCH64_negate_ra_state (== DW_CFA_window_save) operation which > > toggles the return address signedne

[PATCH] aarch64: Fix pac-ret with unusual dwarf in libgcc unwinder [PR104689]

The RA_SIGN_STATE dwarf pseudo-register is normally only set using the DW_CFA_AARCH64_negate_ra_state (== DW_CFA_window_save) operation which toggles the return address signedness state (the default state is 0). (It may be set by remember/restore_state CFI too, those save/restore the state of all r

Re: [PATCH] [RFC][PR102768] aarch64: Add compiler support for Shadow Call Stack

The 11/23/2021 16:32, Dan Li wrote: > On 11/3/21 8:00 PM, Szabolcs Nagy wrote: > > i assume exception handling info has to change for scs to > > work (to pop the shadow stack when transferring control), > > so either scs must require -fno-exceptions or the eh info > >

Re: [PATCH] [RFC][PR102768] aarch64: Add compiler support for Shadow Call Stack

The 11/03/2021 00:24, Dan Li wrote: > On 11/2/21 9:04 PM, Szabolcs Nagy wrote: > > The 11/02/2021 00:06, Dan Li via Gcc-patches wrote: > > > Shadow Call Stack can be used to protect the return address of a > > > function at runtime, and clang already supports this

Re: [PATCH] [RFC][PR102768] aarch64: Add compiler support for Shadow Call Stack

The 11/02/2021 00:06, Dan Li via Gcc-patches wrote: > Shadow Call Stack can be used to protect the return address of a > function at runtime, and clang already supports this feature[1]. > > To enable SCS in user mode, in addition to compiler, other support > is also required (as described in [2]).

Re: Fix handling of stores in modref_summary::useful_p

The 10/05/2020 23:45, Jan Hubicka wrote: > > The 10/05/2020 17:28, Szabolcs Nagy via Gcc-patches wrote: > > minimal reproducer: > > > > #include > > int main() > > { > > int r,t; > > r = sscanf("01", "%2x", &

Re: Fix handling of stores in modref_summary::useful_p

The 10/05/2020 17:28, Szabolcs Nagy via Gcc-patches wrote: > The 10/05/2020 12:52, Vaseeharan Vinayagamoorthy wrote: > > Hi, > > > > After this patch, I am noticing that some glibc crypto tests get stuck in > > scanf which goes into busy loop. > > > > M

Re: Fix handling of stores in modref_summary::useful_p

The 10/05/2020 12:52, Vaseeharan Vinayagamoorthy wrote: > Hi, > > After this patch, I am noticing that some glibc crypto tests get stuck in > scanf which goes into busy loop. > > My build/host/target setup is: > Build: aarch64-none-linux-gnu > Host: aarch64-none-linux-gnu > Target: aarch64-none-

Re: [PING 2][PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

The 09/23/2020 21:45, Jeff Law wrote: > On 9/23/20 11:45 AM, Martin Sebor via Gcc-patches wrote: > > On 9/23/20 9:44 AM, Szabolcs Nagy wrote: > > > The 09/23/2020 09:22, Szabolcs Nagy wrote: > > > > The 09/21/2020 12:45, Martin Sebor via Gcc-patches wrote: > > &

Re: [PING 2][PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

The 09/23/2020 09:22, Szabolcs Nagy wrote: > The 09/21/2020 12:45, Martin Sebor via Gcc-patches wrote: > > On 9/21/20 12:20 PM, Vaseeharan Vinayagamoorthy wrote: > > > After this patch, I am seeing this -Warray-parameter error: > > > > > > In file

Re: [PING 2][PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

The 09/21/2020 12:45, Martin Sebor via Gcc-patches wrote: > On 9/21/20 12:20 PM, Vaseeharan Vinayagamoorthy wrote: > > After this patch, I am seeing this -Warray-parameter error: > > > > In file included from ../include/pthread.h:1, > > from ../sysdeps/nptl/thread_db.h:25, > >

Re: [PATCH] configure: Require C++11 for building code generation tools

The 08/20/2020 13:59, Vasee Vinayagamoorthy wrote: > +# Also require C++11 for building code generation tools. > +# Do nothing if "${build}" = "${host}", because in this case > +# CXX_FOR_BUILD="\$(CXX)", and $CXX is already set to the correct value > above. > +if test "${build}" != "${host}"; the

[PATCH 2/2] aarch64: add PAC-RET protection to libitm sjlj.S

_ITM_beginTransaction is a 'returns_twice' function that saves x30 on the stack as part of gtm_jmpbuf (that is passed down to GTM_begin_transaction), but the saved x30 is also used for return. The return path should be protected so we don't leave an ldp x29, x30, [sp] ret gadget in the code, s

[PATCH 1/2] aarch64: add PAC GNU property note to libgcc lse.S

This note is not used anywhere currently but it is supposed to mark objects if the return address is protected with PAC on the stack. Since lse.S only has leaf functions the return address is never saved on the stack so we can add the note. The note is only added if pac-ret is enabled because it c

Re: [PATCH 4/4] doc: Clarify __builtin_return_address [PR94891]

The 07/13/2020 12:24, Richard Sandiford wrote: > Szabolcs Nagy writes: > > The expected semantics and valid usage of __builtin_return_address is > > not clear since it exposes implementation internals that are normally > > not meaningful to portable c code. > > > >

[PATCH 6/6] aarch64: Fix BTI support in libitm

instructions are added unconditionally. libitm/ChangeLog: 2020-07-08 Szabolcs Nagy * config/aarch64/sjlj.S: Add BTI marking and related definitions, and add BTI c to function entries. --- Note: there is some redundancy: the libgcc fixup patch needed the same macro definitions

[PATCH 4/6] aarch64: Fix noexecstack note in libgcc

lse.S did not have GNU stack note, this may cause missing PT_GNU_STACK in binaries on Linux and FreeBSD. libgcc/ChangeLog: 2020-07-08 Szabolcs Nagy * config/aarch64/lse.S: Add stack note. --- libgcc/config/aarch64/lse.S | 4 1 file changed, 4 insertions(+) diff --git a/libgcc

[PATCH 3/6] aarch64: Fix noexecstack note in libitm

sjlj.S only had the note on Linux, but it is supposed to have it on FreeBSD too. libitm/ChangeLog: 2020-07-08 Szabolcs Nagy * config/aarch64/sjlj.S: Add stack note if __FreeBSD__ is defined. --- Note: this is a minor change to make the asm consistent with gcc code generation (which

[PATCH 5/6] aarch64: Fix BTI support in libgcc

: 2020-07-08 Szabolcs Nagy * config/aarch64/lse.S: Add BTI marking and related definitions, and add BTI c to function entries. --- libgcc/config/aarch64/lse.S | 26 ++ 1 file changed, 26 insertions(+) diff --git a/libgcc/config/aarch64/lse.S b/libgcc/config

[PATCH 1/6] aarch64: Add missing ACLE support for BTI

Define the __ARM_FEATURE_BTI_DEFAULT feature test macro when BTI branch protection is enabled. gcc/ChangeLog: 2020-07-08 Szabolcs Nagy * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Add __ARM_FEATURE_BTI_DEFAULT support. --- gcc/config/aarch64/aarch64-c.c | 3

[PATCH 2/6] aarch64: Add missing ACLE support for PAC-RET

Define the __ARM_FEATURE_PAC_DEFAULT feature test macro when PAC-RET branch protection is enabled. gcc/ChangeLog: 2020-07-08 Szabolcs Nagy * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Add __ARM_FEATURE_PAC_DEFAULT support. --- Note: i expect to push this patch

[PATCH 0/6] aarch64: Fix target libraries for BTI [PR96001]

Some asm files in target libraries were not branch protected and gcc missed preprocessor macros when it is generating branch protection code (which is needed to fix the asm files). Szabolcs Nagy (6): aarch64: Add missing ACLE support for BTI aarch64: Add missing ACLE support for PAC-RET

Re: [PATCH 2/4] aarch64: fix __builtin_eh_return with pac-ret [PR94891]

The 07/08/2020 13:24, Kyrylo Tkachov wrote: > Hi Szabolcs, > > The 06/05/2020 17:51, Szabolcs Nagy wrote: > > > --- a/gcc/config/aarch64/aarch64.c > > > +++ b/gcc/config/aarch64/aarch64.c > > > @@ -6954,6 +6954,10 @@ aarch64_return_address_signing_enabled (vo

Re: [PATCH 3/4] libgcc: fix the handling of return address mangling [PR94891]

The 06/05/2020 17:51, Szabolcs Nagy wrote: > Mangling, currently only used on AArch64 for return address signing, > is an internal representation that should not be exposed via > > __builtin_return_address return value, > __builtin_eh_return handler argument, > _Unwind

Re: [PATCH 2/4] aarch64: fix __builtin_eh_return with pac-ret [PR94891]

The 06/05/2020 17:51, Szabolcs Nagy wrote: > The handler argument must not be signed since that may come from > outside the current module and exposing signed addresses is a pointer > ABI break. (The signed address also may not be representable as void * > which is why pac-ret is curr

Re: [PATCH 1/4] aarch64: fix return address access with pac [PR94891][PR94791]

The 06/05/2020 17:51, Szabolcs Nagy wrote: > This is a big hammer fix for __builtin_return_address (PR target/94891) > returning signed addresses (sometimes, depending on wether lr happens > to be signed or not at the time of call which depends on optimizations), > and similarly

Re: [PATCH 3/4] libgcc: fix the handling of return address mangling [PR94891]

cause ABI issues. (the debugger is special in that it has to know about pointer auth anyway so it's not critical to change this api, but i think it's better to do for consistency) > On 6/5/20 1:51 PM, Szabolcs Nagy wrote: > > Mangling, currently only used on AArch64 for return a

[PATCH 1/4] aarch64: fix return address access with pac [PR94891][PR94791]

the time of return address expansion we don't know if it's signed or not so it is done unconditionally. I wonder if allocate_initial_value for the lr reg may solve this better such that get_hard_reg_initial_val just gives the right (unsigned) value? 2020-06-04 Szabolcs Nagy

[PATCH 3/4] libgcc: fix the handling of return address mangling [PR94891]

instead of a void *.) MD_POST_FROB_EH_HANDLER_ADDR is removed: it is the responsibility of __builtin_eh_return to do the mangling if necessary. libgcc/ChangeLog: 2020-06-04 Szabolcs Nagy * config/aarch64/aarch64-unwind.h (MD_POST_EXTRACT_ROOT_ADDR): Remove

[PATCH 4/4] doc: Clarify __builtin_return_address [PR94891]

affects AArch64 when pointer authentication is used for the return address signing (i.e. -mbranch-protection=pac-ret). gcc/ChangeLog: 2020-06-04 Szabolcs Nagy * doc/extend.texi: Update the text for __builtin_return_address. --- gcc/doc/extend.texi | 16 ++-- 1 file changed

[PATCH 2/4] aarch64: fix __builtin_eh_return with pac-ret [PR94891]

return path with pointer auth since arbitrary target can be reached with the instruction sequence in the caller function anyway, however this is a big hammer solution that turns off pac-ret for the caller completely not just on the eh return path. 2020-06-04 Szabolcs Nagy * config/aarch64

[PATCH 0/4] aarch64: avoid exposing signed return addresses [PR94891]

efore (just with changelog this time). Szabolcs Nagy (4): aarch64: fix return address access with pac [PR94891][PR94791] aarch64: fix __builtin_eh_return with pac-ret [PR94891] libgcc: fix the handling of return address mangling [PR94891] doc: Clarify __builtin_return_address [PR94891] gcc/c

[PATCH] doc: Clarify __builtin_return_address [PR94891]

The expected semantics and valid usage of __builtin_return_address is not clear since it exposes implementation internals that are normally not meaningful to portable c code. This documentation change tries to clarify the semantics in case the return address is stored in a mangled form in memory w

Re: Should ARMv8-A generic tuning default to -moutline-atomics

The 04/30/2020 12:26, Kyrylo Tkachov wrote: > > > From: Gcc On Behalf Of Andrew Pinski via Gcc > > > On Wed, Apr 29, 2020 at 6:25 AM Florian Weimer via Gcc > > > wrote: > > > > Distributions are receiving requests to build things with > > > > -moutline-atomics: > > > > > > > >

Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

The 05/06/2020 11:39, Kyrylo Tkachov wrote: > > -Original Message- > > From: Florian Weimer > > Sent: 06 May 2020 11:28 > > > > Is __gnu_linux__ defined with musl? It's not really GNU/Linux, after > > all. musl doesn't have __getauxval IIRC, so it would break the build > > there. > > I

Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

The 05/04/2020 20:02, Joseph Myers wrote: > On Mon, 4 May 2020, Szabolcs Nagy wrote: > > i think __getauxval needs to be declared where it is used. > > Yes. > > > and libgcc should do a link test in configure becasuse a > > libc may provide sys/auxv.h but not have

Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE detection code in libgcc

The 05/04/2020 11:34, Kyrylo Tkachov wrote: > > -Original Message- > > From: Florian Weimer > > Sent: 04 May 2020 11:40 > > To: Kyrylo Tkachov > > Cc: gcc-patches@gcc.gnu.org; Joseph Myers > > Subject: Re: [PATCH][AArch64] Use __getauxval instead of getauxval in LSE > > detection code in

[PATCH] aarch64: don't emit bti j after NOTE_INSN_DELETED_LABEL [PR94748]

ranch-protection=bti"))) int foo (void) { label: return 0; } This is not necessary and weakens the security protection. gcc/ChangeLog: 2020-04-28 Szabolcs Nagy PR target/94748 * config/aarch64/aarch64-bti-insert.c (rest_of_insert_bti): Remove the

[committed] aarch64: disable test on ilp32 [PR94697]

+ gcc/testsuite/gcc.target/aarch64/pr94697.c | 1 + 2 files changed, 6 insertions(+) diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog index 5a85af479c8..8b23374c591 100644 --- a/gcc/testsuite/ChangeLog +++ b/gcc/testsuite/ChangeLog @@ -1,3 +1,8 @@ +2020-04-27 Szabolcs Nagy

Re: [PATCH v2] aarch64: Fix .cfi_window_save with pac-ret [PR94515]

The 04/24/2020 15:17, Richard Sandiford wrote: > Szabolcs Nagy writes: > > @@ -2221,6 +2239,14 @@ change_cfi_row (dw_cfi_row *old_row, dw_cfi_row > > *new_row) > >cfi->dw_cfi_opc = DW_CFA_GNU_window_save; > >add_cfi (cfi); > > }

[PATCH v2] aarch64: Fix .cfi_window_save with pac-ret [PR94515]

GLE. This should be backported to gcc-9 and gcc-8 branches. gcc/ChangeLog: 2020-04-23 Szabolcs Nagy PR target/94515 * dwarf2cfi.c (struct GTY): Add ra_mangled. (cfi_row_equal_p): Check ra_mangled. (dwarf2out_frame_debug_cfa_window_save): Remove the argument,

[PATCH] aarch64: ensure bti c is emitted at function start [PR94697]

then this situation would be much less common. Needs to be backported to gcc-9 branch. gcc/ChangeLog: 2020-04-XX Szabolcs Nagy PR target/94697 * config/aarch64/aarch64-bti-insert.c (rest_of_insert_bti): Swap bti c and bti j handling. gcc/testsuite/ChangeLog: 2020-04

Re: [PATCH] aarch64, libgcc: Fix unwinding from pac-ret to normal frames [PR94514]

), runtime error for this on a pac-enabled system is nasty. i disabled the test on ilp32 as an obvious fix (attached), and raised PR94729 for the attribute handling in ilp32. thanks for catching this. >From 744b3e4478df83f54543964b8eb7250eb9bb6d40 Mon Sep 17 00:00:00 2001 From: Szabolcs Nagy Dat

Re: [PATCH] aarch64, libgcc: Fix unwinding from pac-ret to normal frames [PR94514]

The 04/17/2020 11:05, Kyrylo Tkachov wrote: > Hi Szabolcs, > > > -Original Message- > > From: Szabolcs Nagy > > Sent: 09 April 2020 15:20 > > To: gcc-patches@gcc.gnu.org > > Cc: Richard Earnshaw ; Richard Sandiford > > ; Kyrylo Tkachov > >

Re: [PATCH] aarch64: Fix .cfi_window_save with pac-ret [PR94515]

The 04/17/2020 15:26, Jason Merrill wrote: > On 4/17/20 1:55 PM, Szabolcs Nagy wrote: > > The 04/17/2020 12:50, Jason Merrill wrote: > > > On 4/17/20 6:08 AM, Kyrylo Tkachov wrote: > > > > Hi Szabolcs, > > > > > > > > > -Original Messa

Re: [PATCH] aarch64: Fix .cfi_window_save with pac-ret [PR94515]

The 04/17/2020 12:50, Jason Merrill wrote: > On 4/17/20 6:08 AM, Kyrylo Tkachov wrote: > > Hi Szabolcs, > > > > > -Original Message----- > > > From: Szabolcs Nagy > > > Sent: 09 April 2020 15:20 > > > To: gcc-patches@gcc.gnu.org > >

[PATCH] aarch64, libgcc: Fix unwinding from pac-ret to normal frames [PR94514]

: 2020-04-XX Szabolcs Nagy PR target/94514 * g++.target/aarch64/pr94514.C: New test. * gcc.target/aarch64/pr94514.c: New test. libgcc/ChangeLog: 2020-04-XX Szabolcs Nagy PR target/94514 * config/aarch64/aarch64-unwind.h (aarch64_frob_update_context

[PATCH] aarch64: Fix .cfi_window_save with pac-ret [PR94515]

ate return addresses that were signed (or vice versa) which means a runtime crash on a pauth enabled system. Currently only aarch64 pac-ret uses REG_CFA_TOGGLE_RA_MANGLE. gcc/ChangeLog: 2020-04-XX Szabolcs Nagy PR target/94515 * dwarf2cfi.c (dwarf2out_frame_debug):

Re: [PATCH] avoid treating more incompatible redeclarations as builtin-ins [PR94040]

The 03/13/2020 10:45, Martin Sebor via Gcc-patches wrote: > On 3/12/20 7:17 PM, Joseph Myers wrote: > > On Thu, 5 Mar 2020, Martin Sebor wrote: > > > > > Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9? > > > > OK for GCC 10. > > Thank you. I committed it to trunk in r10-71

  1   2   3   4   >