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
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
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
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
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
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
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
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
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
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
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.
I'm working on Guarded Control Stack support for aarch64 and have a
set of patches that are needed for GCS but seem useful without it so
makes sense to review them separately from the rest of the GCS work.
GCS support will depend on the linux ABI that is under discussion at
https://lore.kernel.org
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 *
> >>
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
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
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
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
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
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
> > changes must be implemented.
>
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 feature[1].
> > >
> > > To enable
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]).
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", &
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
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-
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:
> > > > > On 9/21/20 12:20 PM, Vaseeharan
25 matches
Mail list logo
