Tarantool development patches archive
 help / color / mirror / Atom feed
From: Alexander Turenko <alexander.turenko@tarantool.org>
To: AKhatskevich <avkhatskevich@tarantool.org>
Cc: georgy@tarantool.org, tarantool-patches@freelists.org
Subject: [tarantool-patches] Re: [PATCH 1/3] Fix: prevent guard-breaker optimization
Date: Wed, 10 Oct 2018 17:26:11 +0300	[thread overview]
Message-ID: <20181010142610.m7aojo6ro5cuvpqq@tkn_work_nb> (raw)
In-Reply-To: <ee81c4f7e457319226c9ed5f9ac9f926e8d617ef.1533726342.git.avkhatskevich@tarantool.org>

On Wed, Aug 08, 2018 at 02:10:01PM +0300, AKhatskevich wrote:
> In case of very aggressive optimizations the compiler can
> optimize guard-breaker function away and the `unit/guard`
> test would fail.

I think it is good to mention the specific compiler options (and a
certain compiler you are using to reproduce it) to give a user an idea
when things are going wrong and so what is the fix does.

Is it due to discarding the noinline attribute in case of LTO on gcc? So
'volatile' prevents inlining the function? I just guessing here, but I
think the commit message should clarify such things if possible.

> ---
>  test/unit/guard.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/test/unit/guard.cc b/test/unit/guard.cc
> index 231b44c7d..2082dfd48 100644
> --- a/test/unit/guard.cc
> +++ b/test/unit/guard.cc
> @@ -13,7 +13,7 @@ static int __attribute__((noinline))
>  stack_break_f(char *ptr)
>  {
>  	char block[2048];
> -	char sum = 0;
> +	volatile char sum = 0;

I think a reason of using 'volatile' keyword should be always properly
commented in the code, because it always fix some unobvious compiler
behaviour.

>  	memset(block, 0xff, 2048);
>  	sum += block[block[4]];
>  	ptrdiff_t stack_diff = ptr > block ? ptr - block : block - ptr;
> -- 
> 2.14.1
> 
> 

  reply	other threads:[~2018-10-10 14:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-08 11:10 [tarantool-patches] [PATCH 0/3] LTO && travis AKhatskevich
2018-08-08 11:10 ` [tarantool-patches] [PATCH 1/3] Fix: prevent guard-breaker optimization AKhatskevich
2018-10-10 14:26   ` Alexander Turenko [this message]
2018-10-11 16:02     ` [tarantool-patches] " Alex Khatskevich
2018-08-08 11:10 ` [tarantool-patches] [PATCH 2/3] Add LTO support AKhatskevich
2018-10-10 14:29   ` [tarantool-patches] " Alexander Turenko
2018-10-11 16:01     ` Alex Khatskevich
2018-08-08 11:10 ` [tarantool-patches] [PATCH 3/3] Add LTO testing && refactor travis.yml AKhatskevich
2018-10-10 14:43   ` [tarantool-patches] " Alexander Turenko
2018-10-11 16:12 ` [tarantool-patches] [PATCH] Enable 0069 policy AKhatskevich
2018-10-11 16:14 ` [tarantool-patches] [tarantool-small] " AKhatskevich
2018-10-11 16:15 ` [tarantool-patches] [tarantool-libyaml] " AKhatskevich
2018-10-11 16:18 ` [tarantool-patches] [tarantool-msgpuck] " AKhatskevich

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=20181010142610.m7aojo6ro5cuvpqq@tkn_work_nb \
    --to=alexander.turenko@tarantool.org \
    --cc=avkhatskevich@tarantool.org \
    --cc=georgy@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --subject='[tarantool-patches] Re: [PATCH 1/3] Fix: prevent guard-breaker optimization' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox