Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp12864imu; Wed, 19 Dec 2018 12:43:46 -0800 (PST) X-Google-Smtp-Source: AFSGD/X79ElwoiCfMIBEP4y3YKhD4GKarALTcoOQUTHp5Wqp1SB24p9Tl1t34b+jkVoqB6xWISE7 X-Received: by 2002:a63:3e05:: with SMTP id l5mr3057741pga.96.1545252226126; Wed, 19 Dec 2018 12:43:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545252226; cv=none; d=google.com; s=arc-20160816; b=bG1vyffgDjV7SNdIyeqOFDIbxX3jnHu6Fkr4bYjNkgeZFq7R0DWvMj3iIVihzFboGF bew6rFIpUlJfYxEjoto2n90CLNX9mQRW2HUEIxCnzVRUDmQkoTzOlktSGd7WFYMxNSZL sdECUEsaBTnCeeU1iTsIG5FijXl1yiwQhDIZpM8pyl+8NxpDXkTrCu60fjKK4EuWvS3B TAzBgHvOdBkX7ApNZ12LFL8l6KQaReXfO28U3/EQUZJ/89NPh2DdLsxqHT/KbXQOPvp3 gqI02vGIUfKuaaVl7K10/oayCuSZ+mV5MLiB3jpDLcw36TieuVVyjfx4jWLlY2WDHirA gW6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from; bh=fU6iGOiwDE4qVJ7WeRj0zfYmJ4+gpITChlCgOfR6Jvk=; b=sHUpm3FRnFt7KKkW44BPwArUkLJvMZUuoRkD/jaUEXJkUHkgk4DAUbpTdXSHcuVYab Q8NhqhZvn2bM1Dqs3LBpf/jZSSI07F8O/a8qRuuv4kK70867vfFqdHv/QjLowJro49F8 uOhjjG5qe1ACNJ/dsRsyC8hrqbd3gIngnXfEuXO8baDmeiVfS4ux6vnWwn6hMJAf8lr1 az6FktN9Vzqa7LP0NIvjMeBh3UuHJaPrw/gmZMdrjLekWcDpQdCviWQKHLt8oNxCKBLP SE1rRuXshJlv+gAUCvKqLeecUuSEV3OqTN5VIBaCNyp9PWx/TOTyYTXFmnDs+LDT+S/u V9jg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a10si16053665pgq.270.2018.12.19.12.43.29; Wed, 19 Dec 2018 12:43:46 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730554AbeLSRbT (ORCPT + 99 others); Wed, 19 Dec 2018 12:31:19 -0500 Received: from mx2.suse.de ([195.135.220.15]:49270 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728582AbeLSRbS (ORCPT ); Wed, 19 Dec 2018 12:31:18 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D46A8B187; Wed, 19 Dec 2018 17:31:15 +0000 (UTC) From: Martin Jambor To: Josh Poimboeuf Cc: Miroslav Benes , Andi Kleen , Steven Rostedt , Peter Zijlstra , Arnd Bergmann , Linux Kernel Mailing List , "the arch\/x86 maintainers" Subject: Re: objtool warnings for kernel/trace/trace_selftest_dynamic.o In-Reply-To: <20181218140105.ajuiglkpvstt3qxs@treble> References: <20181217173900.ygifx7khwmzn2gv2@treble> <20181217180434.GS25620@tassilo.jf.intel.com> <20181217181638.dfexg6mkmbfyzfli@treble> <20181217192938.GF2218@hirez.programming.kicks-ass.net> <20181217213126.lsqhyszoulel6uq6@treble> <20181217173644.391c2070@gandalf.local.home> <20181218000618.GA25620@tassilo.jf.intel.com> <20181218024916.vmfnyqzouhfxhyvc@treble> <20181218140105.ajuiglkpvstt3qxs@treble> User-Agent: Notmuch/0.26 (https://notmuchmail.org) Emacs/26.1 (x86_64-suse-linux-gnu) Date: Wed, 19 Dec 2018 18:31:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Tue, Dec 18 2018, Josh Poimboeuf wrote: > On Tue, Dec 18, 2018 at 01:15:40PM +0100, Martin Jambor wrote: >> I'm afraid I cannot give an opinion what you should do in this case >> without understanding the problem better. If you can isolate the case >> where noclone behaves weirdly into a self-contained testcase, I'd be >> happy to have a look at it. > > I whittled it down to a small test case. It turns out the problem is > caused by the "__optimize__("no-tracer")" atribute, which is used by our > __noclone macro: Wonderful, thanks a lot. > > # if __has_attribute(__optimize__) > # define __noclone __attribute__((__noclone__, __optimize__("no-tracer"))) > # else > # define __noclone __attribute__((__noclone__)) > # endif > > > Here's the test case. Notice it skips the frame pointer setup before > the call to __sanitizer_cov_trace_pc(): > > > $ cat test.c > __attribute__((__optimize__("no-tracer"))) int test(void) > { > return 0; > } > $ gcc -O2 -fno-omit-frame-pointer -fsanitize-coverage=trace-pc -c -o test.o test.c Well, it might not be intuitive but the __optimize__ attribute resets to -O2 optimization defaults and thus drops -fno-omit-frame-pointer on the floor, so no wonder there is no frame pointer. This applies to other optimization options you pass on the command line, for example if you still compile kernel with -fno-strict-aliasing, you get GCC assuming strict aliasing in functions marked with your __noclone. > Apparently we are using "no-tracer" because of: > > > commit 95272c29378ee7dc15f43fa2758cb28a5913a06d > Author: Paolo Bonzini > Date: Thu Mar 31 09:38:51 2016 +0200 > > compiler-gcc: disable -ftracer for __noclone functions > > -ftracer can duplicate asm blocks causing compilation to fail in > noclone functions. For example, KVM declares a global variable > in an asm like > > asm("2: ... \n > .pushsection data \n > .global vmx_return \n > vmx_return: .long 2b"); > > and -ftracer causes a double declaration. There is no way for a user to reliably prevent a duplication of an inline assembly statement. The correct fix is to move such statements to an assembly files. You have disabled tracer which duplicated it in your case but other passes might do that too in the future. The correct fix is to put such assembler snippets into separate assembly files or, if you for for some reason insist on inline assembly, to use '%=' inline assembler template format string (it is expanded to a number that is unique in a compilation unit). Martin