Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4350193imu; Tue, 18 Dec 2018 13:16:07 -0800 (PST) X-Google-Smtp-Source: AFSGD/WbORnWuVhhzwwnVoZiAE978A6xc1KG8xtECjNYXHgyjN5CY2T29zkuBimgFU0lLvYu9b0H X-Received: by 2002:a63:111c:: with SMTP id g28mr17032675pgl.85.1545167767740; Tue, 18 Dec 2018 13:16:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545167767; cv=none; d=google.com; s=arc-20160816; b=eXAGCu0y+9o0PoD1w3TjYglgRzviCCzYTnyecGzW0o0quiBq0vPPaZMCFLMFJlxUp0 72hJYt0haBJNewdvoWnHJ565Q4XOh2c/eiXrQDpfHXeLcabGUVL8IzwPclaJtVltk9iL ThOlJMxU4YH2/ltr++GsaCjFBzsEU70Uolojm6L7Mbx4vj/9fPzdGraVQ0Z9V7Xl8VgL 99GLyYSi6Q81LzhCORapMUspEfC6XkLpXsNQZuJR+quIWDizSyRGhqcdIUNUJl40Egu2 GecRvTLfOImw8jgkc2grwbDSP5TYCcCs+ZrtOCRKVX6tcYk/IGXYSJgzbc0vVe/J4tH5 YwtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=OzJYiKm1ecLtRaum3+CgkhdMENEnMHoFOeoXYLa8FiE=; b=PtvnEZI+YjYMRSohA6cywiEAQytMuC1UgN0/lzWn845uS06e6zLVUBQV2GNtTH28xb iJM3yVtAvm9Ur6X6B2wDo+HyQlPjlskVEBp8fAc7NrzFQm9GUGMsxY18fsFD5yHmExnY BaMHQSQ1UNPXWAjfRN/6rTPyM1leTRtUim8+G9ypLlRcq3kRZFGs+Lko6V5aF/1t52e7 myyTcg8OGDcr4QIITl1kJdfsHkyFzYbZHAa1m9MPzMYbhpAX/Aq77GlewpL8z5171NLz uCEDU5tXHcShylmjPOrOsKHmR9toiKamOISAOtFTE7x1+u34FdstNOpsNgtScUTAAn0g A71A== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 76si14779087pfw.66.2018.12.18.13.15.52; Tue, 18 Dec 2018 13:16:07 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726750AbeLRVPD (ORCPT + 99 others); Tue, 18 Dec 2018 16:15:03 -0500 Received: from mga09.intel.com ([134.134.136.24]:63187 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726451AbeLRVPC (ORCPT ); Tue, 18 Dec 2018 16:15:02 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2018 13:15:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,370,1539673200"; d="scan'208";a="119358924" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.7.201.137]) by orsmga002.jf.intel.com with ESMTP; 18 Dec 2018 13:15:01 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id C4992300B49; Tue, 18 Dec 2018 13:15:01 -0800 (PST) Date: Tue, 18 Dec 2018 13:15:01 -0800 From: Andi Kleen To: Martin Jambor Cc: Miroslav Benes , Josh Poimboeuf , 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 Message-ID: <20181218211501.GD25620@tassilo.jf.intel.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > OK, I have read through it and with the caveats that I don't quite > understand what the failure is, that also believe attribute noclone > should not affect frame pointer generation, and that I don't quite get > how LTO comes into play, my comments are the following: > > I am the developer who introduced attribute noclone to GCC and also the > one who advises against using it :-) ...at least without also using the > noinline attribute, the combination means " The function in question uses noinline too. > I want only one or zero > copies of this function in the compiled assembly" which you might need > if you do fancy stuff in inline assembly, for example. For this case we only want one non inlined copy because it is used as a test case for a function tracer. LTO comes into play because it originally relied on being in a separate file, so it would not be inlined, but with LTO that doesn't work. > > I believe that when people use noclone on its own, in 99 out 100 cases > they actually want something else. Usually there is something that AFAIK there is no noclone without noinline in the kernel tree. > references the function from code (such as assembly) or a tool that the > compiler does know about and then they should use the "used" attribute. Neither in the ftrace case, nor in the KVM case (another user which has fancy inline assembly that cannot be duplicated) that's the case. It's just about having exactly one out of line instance. So based on that I think noclone is fine. Of course there is still the open question why exactly the frame pointer disappears. -Andi