Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp702943ybh; Wed, 22 Jul 2020 10:59:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJylmEC7e3G2dIMe/vC8UUYmmbV/v/6wfeSQdMAeIiw9ntzoALCt15p0whwLe2f44pE8FU+t X-Received: by 2002:aa7:c90a:: with SMTP id b10mr626651edt.71.1595440767586; Wed, 22 Jul 2020 10:59:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595440767; cv=none; d=google.com; s=arc-20160816; b=Oa7vyEGzHzD8zmrPFBSLhs2tPLsNzJ+fGPNpfgNDlZFhmt99tcAfv9w8kkOk7LKMH7 FQzlm0DBbvQyPNjAgPwZqJ/6uqMSw3+D6sc7cvE7lc27LcgP6K7IN3+NjUpJt73z0ARB JTFLVVEBCg/I6PmzzP0Yd5Y/ZJVOuLQewNbUvsIOTihma8b+zii8NcQlohOcww35CHqm ej+g2tqXjr09a3YIQZQbeQAFYJ9pNfK2MNJToRXwUvZqEO0ZLYSjxYYVTLdBS3Cx9Bid wSvZMPu47+pnlV+m0zPPU3N9emDqQnpW53zdBtWlHAj3WtX5lJWTasy8dOm29SKC3cGE MELA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=W2OAjV3xPwVZMyes/HQ95gYX51/dKuWvHqkEa2QTLxo=; b=W1EzKcU6LmBz3BIHJJQfl5x6eKanopBcpIu+Qk3PH0n0fOLcwDYOAAQwslaDLPt+hU 5uEyJy7zWxYnhQHZ7dwaPuJee19m7TqC/dLs0s4CZTihzdT0I1OGuhoi0GD5UQntQV12 bSfKsvprO1lTQKOUCvXDDj3CIbfTkVyWBrse05ruCyBrohppda+SEPb1llTs8Rg1nUaO Ix2wxXy6ko4FRfarYEIQ6ByFqWvgg1ddYsb+gVDwXSj9fPhz/2Hhee4Js6cr+0ueLCJz Ia2AHjR1NXLDi5EdB4N1aUHd9GI9D7AEXduBV1wpZGmJ4THoKKd2+GYqXf4aXgWwILnQ Ov6g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a22si429203ejj.163.2020.07.22.10.59.04; Wed, 22 Jul 2020 10:59:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727818AbgGVR6k (ORCPT + 99 others); Wed, 22 Jul 2020 13:58:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:50674 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726666AbgGVR6k (ORCPT ); Wed, 22 Jul 2020 13:58:40 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 59D79208E4; Wed, 22 Jul 2020 17:58:38 +0000 (UTC) Date: Wed, 22 Jul 2020 13:58:36 -0400 From: Steven Rostedt To: Sami Tolvanen Cc: Peter Zijlstra , Masahiro Yamada , Will Deacon , Greg Kroah-Hartman , "Paul E. McKenney" , Kees Cook , Nick Desaulniers , clang-built-linux , Kernel Hardening , linux-arch , linux-arm-kernel , linux-kbuild , LKML , linux-pci@vger.kernel.org, X86 ML , Josh Poimboeuf Subject: Re: [RFC][PATCH] objtool,x86_64: Replace recordmcount with objtool Message-ID: <20200722135829.7ca6fbc5@oasis.local.home> In-Reply-To: References: <20200624203200.78870-1-samitolvanen@google.com> <20200624203200.78870-5-samitolvanen@google.com> <20200624212737.GV4817@hirez.programming.kicks-ass.net> <20200624214530.GA120457@google.com> <20200625074530.GW4817@hirez.programming.kicks-ass.net> <20200625161503.GB173089@google.com> <20200625200235.GQ4781@hirez.programming.kicks-ass.net> <20200625224042.GA169781@google.com> <20200626112931.GF4817@hirez.programming.kicks-ass.net> <20200717133645.7816c0b6@oasis.local.home> <20200717140545.6f008208@oasis.local.home> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 20 Jul 2020 09:52:37 -0700 Sami Tolvanen wrote: > > Does x86 have a way to differentiate between the two that record mcount > > can check? > > I'm not sure if looking at the relocation alone is sufficient on x86, > we might also have to decode the instruction, which is what objtool > does. Did you have any thoughts on Peter's patch, or my initial > suggestion, which adds a __nomcount attribute to affected functions? There's a lot of code in this thread. Can you give me the message-id of Peter's patch in question. Thanks, -- Steve