public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: liuhongt <hongtao.liu@intel.com>
Cc: gcc-patches@gcc.gnu.org, crazylht@gmail.com, hjl.tools@gmail.com
Subject: Re: [PATCH] sanitizer: [PR110027] Align asan_vec[0] to MAX (alignb, ASAN_RED_ZONE_SIZE)
Date: Mon, 25 Mar 2024 13:51:12 +0100	[thread overview]
Message-ID: <ZgFzQLtmPffEK+93@tucnak> (raw)
In-Reply-To: <20240312115759.4067084-1-hongtao.liu@intel.com>

On Tue, Mar 12, 2024 at 07:57:59PM +0800, liuhongt wrote:
> if alignb > ASAN_RED_ZONE_SIZE and offset[0] is not multiple of
> alignb. (base_align_bias - base_offset) may not aligned to alignb, and
> caused segement fault.
> 
> Bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
> Ok for trunk and backport to GCC13?
> 
> gcc/ChangeLog:
> 
> 	PR sanitizer/110027
> 	* cfgexpand.cc (expand_stack_vars): Align frame offset to
> 	MAX (alignb, ASAN_RED_ZONE_SIZE).
> 
> gcc/testsuite/ChangeLog:
> 
> 	* g++.dg/asan/pr110027.C: New test.
> ---
>  gcc/cfgexpand.cc                     |  2 +-
>  gcc/testsuite/g++.dg/asan/pr110027.C | 20 ++++++++++++++++++++
>  2 files changed, 21 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/g++.dg/asan/pr110027.C
> 
> diff --git a/gcc/cfgexpand.cc b/gcc/cfgexpand.cc
> index 0de299c62e3..92062378d8e 100644
> --- a/gcc/cfgexpand.cc
> +++ b/gcc/cfgexpand.cc
> @@ -1214,7 +1214,7 @@ expand_stack_vars (bool (*pred) (size_t), class stack_vars_data *data)
>  	    {
>  	      if (data->asan_vec.is_empty ())
>  		{
> -		  align_frame_offset (ASAN_RED_ZONE_SIZE);
> +		  align_frame_offset (MAX (alignb, ASAN_RED_ZONE_SIZE));
>  		  prev_offset = frame_offset.to_constant ();
>  		}
>  	      prev_offset = align_base (prev_offset,

This doesn't look correct to me.
The above is done just once for the first var partition.  And
var partitions are sorted by stack_var_cmp, which puts > MAX_SUPPORTED_STACK_ALIGNMENT
alignment vars first (that should be none on x86, the above is quite huge
alignment), then on size decreasing and only after that on alignment
decreasing.

So, try to add some other variable with larger size and smaller alignment
to the frame (and make sure it isn't optimized away).

alignb above is the alignment of the first partition's var, if
align_frame_offset really needs to depend on the var alignment, it probably
should be the maximum alignment of all the vars with alignment
alignb * BITS_PER_UNIT <= MAX_SUPPORTED_STACK_ALIGNMENT

> diff --git a/gcc/testsuite/g++.dg/asan/pr110027.C b/gcc/testsuite/g++.dg/asan/pr110027.C
> new file mode 100644
> index 00000000000..0067781bc89
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/asan/pr110027.C
> @@ -0,0 +1,20 @@
> +/* PR sanitizer/110027 */
> +/* { dg-do run } */
> +/* { dg-require-effective-target avx512f_runtime } */
> +/* { dg-options "-std=gnu++23 -mavx512f -fsanitize=address -O0 -g -fstack-protector-strong" } */
> +
> +#include <cstddef>
> +#include <cstdint>
> +
> +template <ptrdiff_t W, typename T>
> +using Vec [[gnu::vector_size(W * sizeof(T))]] = T;
> +
> +auto foo() {
> +  Vec<8, int64_t> ret{};
> +  return ret;
> +}
> +
> +int main() {
> +  foo();
> +  return 0;
> +}
> -- 
> 2.31.1

	Jakub


  parent reply	other threads:[~2024-03-25 12:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-12 11:57 liuhongt
2024-03-13  1:27 ` Hongtao Liu
2024-03-25 12:51 ` Jakub Jelinek [this message]
2024-03-26  3:26   ` Hongtao Liu
2024-03-26  3:34     ` Hongtao Liu
2024-03-26  6:08       ` [PATCH V2] sanitizer: [PR110027] Align asan_vec[0] to MAX (BIGGEST_ALIGNMENT / BITS_PER_UNIT, ASAN_RED_ZONE_SIZE) liuhongt
2024-04-11  8:38         ` [PATCH] asan, v3: Fix up handling of > 32 byte aligned variables with -fsanitize=address -fstack-protector* [PR110027] Jakub Jelinek
2024-04-11  8:53           ` Richard Biener
2024-04-11 11:13           ` Liu, Hongtao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZgFzQLtmPffEK+93@tucnak \
    --to=jakub@redhat.com \
    --cc=crazylht@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hjl.tools@gmail.com \
    --cc=hongtao.liu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).