Hello, Bootstrapped and regression tested on AArch64 (have not finished running tests on the Linux Kernel yet). Sending upstream to catch next set of comments early.
This version mainly just consists of requested changes. Some notable exceptions: Have rebased onto a newer version, there was a change to `align_local_variable` that meant some merge conflict resolutions were needed (though no functional change expected). Alignment of stack after object: In Patch 5/X (for tagging objects on the stack) I realised that in some code paths the current method was not ensuring alignment of the stack *after* the object in memory for !FRAME_GROWS_DOWNWARDS. There is a comment in `expand_stack_vars`, alongside the update. Originally we used `align_frame_offset` before space for the object gets allocated to ensure the stack is aligned after the object, and `alloc_stack_frame_space` with relevant alignment to ensure the stack is aligned before the object. When !FRAME_GROWS_DOWNWARDS, using `align_frame_offset` before the object space is allocated does not ensure alignment of the next object. Rather we must use `align_frame_offset` after space is allocated. I now use `align_frame_offset` before *and* after `alloc_stack_frame_space`. This looks nicer than putting if conditions based on FRAME_GROWS_DOWNWARDS and does not end up allocating any extra space than only calling the align function once (it just means the alignment from the `alloc_stack_frame_space` is superfluous). I still ensure `align_local_variable` returns the correct alignment, even though it makes no functional difference. This seems less likely to cause confusion to me. Similarly, this function still uses `SET_DECL_ALIGN` to correctly advertise the alignment that the stack variable is aligned to. (N.b. testing does show that leaving `align_local_variable` as it is doesn't break anything, which is as expected since the alignment is ensured by the calls to `align_frame_offset`). Ensure Alloca causes hwasan frame base to get initialised. In the last version of this patch `expand_HWASAN_CHOOSE_TAG` would use the hwasan frame base using `hwasan_base`. Since this function is used after `expand_stack_vars` and hence after `hwasan_emit_prologue` that would not cause the initialisation of the frame base to be emitted, but would just use the pseudo register without any initialisation. This patch records that initialisation should be emitted when creating the `HWASAN_CHOOSE_TAG` internal function -- so that even if there are no statically allocated local variables the hwasan frame base will be initialisied. New test was introduced to catch this. Introduce HWASAN_SET_TAG internal function. This was something that popped up during testing the linux kernel with stack-tagging. The __hwasan_tag_pointer interface exported by libhwasan is not available in the kernel. Since the main target of putting this feature in GCC is for the kernel we deal with this by emitting code inline to set a tag in a pointer. New test to ensure HWASAN_MARK can handle poly_int sizes. The code is designed to handle any variable sized object, but the only sizes that could actually be used happen to be poly_int sized variables. This is essentially the testcase from pr97696. HWASAN can handle such size types (though ASAN can't) so this should pass for HWASAN. Thanks, Matthew Entire patch series attached to cover letter.
all-patches.tar.gz
Description: application/gzip
