From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 41D082CE11 for ; Thu, 11 Oct 2018 12:02:25 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQ43VYeXnqjN for ; Thu, 11 Oct 2018 12:02:25 -0400 (EDT) Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id EFBCE2C119 for ; Thu, 11 Oct 2018 12:02:24 -0400 (EDT) From: Alex Khatskevich Subject: [tarantool-patches] Re: [PATCH 1/3] Fix: prevent guard-breaker optimization References: <20181010142610.m7aojo6ro5cuvpqq@tkn_work_nb> Message-ID: Date: Thu, 11 Oct 2018 19:02:23 +0300 MIME-Version: 1.0 In-Reply-To: <20181010142610.m7aojo6ro5cuvpqq@tkn_work_nb> Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: Alexander Turenko Cc: georgy@tarantool.org, tarantool-patches@freelists.org On 10.10.2018 17:26, Alexander Turenko wrote: > 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. Discussed verbally. Added a comment near volatile keyword. >> memset(block, 0xff, 2048); >> sum += block[block[4]]; >> ptrdiff_t stack_diff = ptr > block ? ptr - block : block - ptr; >> -- >> 2.14.1 >> >> New diff: commit d7acdc09aa471ea15b3821bab205d8fcdb9280c1 Author: AKhatskevich Date:   Tue Aug 7 16:47:39 2018 +0300     Fix: prevent guard-breaker optimization     In case of very aggressive optimizations the compiler can     optimize guard-breaker function away and the `unit/guard`     test would fail. diff --git a/test/unit/guard.cc b/test/unit/guard.cc index 231b44c7d..3d42fee31 100644 --- a/test/unit/guard.cc +++ b/test/unit/guard.cc @@ -13,7 +13,11 @@ static int __attribute__((noinline))  stack_break_f(char *ptr)  {      char block[2048]; -    char sum = 0; +    /* +     * Make sum volatile to prevent a compiler from +     * optimizing away call to this function. +     */ +    volatile char sum = 0;      memset(block, 0xff, 2048);      sum += block[block[4]];      ptrdiff_t stack_diff = ptr > block ? ptr - block : block - ptr;