Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp976896ybx; Wed, 30 Oct 2019 08:05:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqyfi9gNWpSXBB8blzYx+1C2hh2JMs+mxpcjdO/PasyORAZ38wJFWnPED6+GxCMEiIOKZn9P X-Received: by 2002:a17:906:5919:: with SMTP id h25mr5434971ejq.222.1572447936182; Wed, 30 Oct 2019 08:05:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572447936; cv=none; d=google.com; s=arc-20160816; b=sAMxfUP/OdcKygOB5sqxQwqg+K8rvwptmdl0zxWFTSQM7NXqOU484rURD8REGEHGH+ B3ipWS8FSzAOmhhR/8tRAnVD469/dUWg8DhG3pStTUQcvFxxXqOhd5jD2bYkTRKFnXxi hevYfGoiVk9T16DWHLdSKAOgiQIVfFMwlZWR3zwvm+MYoTSzhPqDEoEUaaaXGlHkV1K9 XszpbXessQ+eu3UeyCRW3eh7243b41pqXS4VzgXLPMGvgwHeCc+wsru7SERFNpMv3+AX yXIT3fVj//oSMeVyXi8WTvRkxd777+xQScLsiPX4deq8s5Au/u4Vs8adQpi+yr7x8YBw zYow== 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=/rADrBlz9BEnAxBJprDm5dSrJnRYq5NzqWVfgl3btdI=; b=x5TTd95KLEKGYPpwTCvisLO6IO3nPXqQ7ig6wBqc0GGOI2kHh4qCDPvtUtAh580fYR n5VK3SqKCh94QTsqaPp4hwaGhG34s9+wQlvS80WfohXAc5x6zax6f8CnxwEdXOPRcmBh ab5CAGtyb7ZJ5p+3qFS30E9U2dhP4ZpfNPVamcVL2LpRwvJO8MtxzFHd8IJFof9fA7jX bLYPXORzhispsCIUErkVNh09wYnG8yfekn606ErBo9uiSCYyT+aE5R5Wo5Q+jtdN/88H dF1ELJpIN9mN13NgncRpp1q7i5x4Na2PtGE5gdilcBF4dW/LjORf300HhWajzXBbAVaE Pj7g== 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 z25si1411090eju.56.2019.10.30.08.04.59; Wed, 30 Oct 2019 08:05:36 -0700 (PDT) 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 S1727003AbfJ3PDG (ORCPT + 99 others); Wed, 30 Oct 2019 11:03:06 -0400 Received: from mx2.suse.de ([195.135.220.15]:48256 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726175AbfJ3PDF (ORCPT ); Wed, 30 Oct 2019 11:03:05 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D41D1B3B1; Wed, 30 Oct 2019 15:03:03 +0000 (UTC) Date: Wed, 30 Oct 2019 16:03:02 +0100 From: Torsten Duwe To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, Jessica Yu , Helge Deller , "James E.J. Bottomley" , linux-kernel@vger.kernel.org, amit.kachhap@arm.com, catalin.marinas@arm.com, james.morse@arm.com, jpoimboe@redhat.com, jthierry@redhat.com, linux-parisc@vger.kernel.org, mingo@redhat.com, peterz@infradead.org, rostedt@goodmis.org, svens@stackframe.org, takahiro.akashi@linaro.org, will@kernel.org Subject: Re: [PATCHv2 2/8] module/ftrace: handle patchable-function-entry Message-ID: <20191030150302.GA965@suse.de> References: <20191029165832.33606-1-mark.rutland@arm.com> <20191029165832.33606-3-mark.rutland@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191029165832.33606-3-mark.rutland@arm.com> 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 On Tue, Oct 29, 2019 at 04:58:26PM +0000, Mark Rutland wrote: > When using patchable-function-entry, the compiler will record the > callsites into a section named "__patchable_function_entries" rather > than "__mcount_loc". Let's abstract this difference behind a new > FTRACE_CALLSITE_SECTION, so that architectures don't have to handle this > explicitly (e.g. with custom module linker scripts). > > As parisc currently handles this explicitly, it is fixed up accordingly, > with its custom linker script removed. Since FTRACE_CALLSITE_SECTION is > only defined when DYNAMIC_FTRACE is selected, the parisc module loading > code is updated to only use the definition in that case. When > DYNAMIC_FTRACE is not selected, modules shouldn't have this section, so > this removes some redundant work in that case. > > I built parisc generic-{32,64}bit_defconfig with DYNAMIC_FTRACE enabled, > and verified that the section made it into the .ko files for modules. This is because of remaining #ifdeffery in include/asm-generic/vmlinux.lds.h: #ifdef CC_USING_PATCHABLE_FUNCTION_ENTRY #define MCOUNT_REC() . = ALIGN(8); \ __start_mcount_loc = .; \ KEEP(*(__patchable_function_entries)) \ __stop_mcount_loc = .; #else #define MCOUNT_REC() . = ALIGN(8); \ __start_mcount_loc = .; \ KEEP(*(__mcount_loc)) \ __stop_mcount_loc = .; #endif Maybe you want to tackle that as well? I suggest to have at least one FTRACE_CALLSITE_SECTION definition without double quotes. Alternatively, my earlier solution just kept both sections, in case either one or both are present. KEEP(*(__patchable_function_entries)) \ KEEP(*(__mcount_loc)) \ Torsten