From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-17.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6ABF1C43460 for ; Fri, 7 May 2021 20:57:36 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DDDE060FD8 for ; Fri, 7 May 2021 20:57:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DDDE060FD8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-Id:Date: Subject:Cc:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=MBendgBYis5TA+/GJZpsIloDQx61wG6C57UGUX6Ndt0=; b=dhzhHhTbM3ivfaHh1qcSfLi0H Tkmi41/0HX4q1fJN4Lveku/KREb6Q7rEbSWQTCjR3WJN5XGM+0LkBBc3ri9DcXnYtkOXFnv+Hk8V/ yTYiJOuctR1dnp7niaMGZm4QoperZoWYI4VOxBvfjRxGZqKv/oWb31SMka1dc/5lVaLIliqNUJ2fC 0t/GskYYaf5R691yfFhLPIe1M3R2tbPH0qKSW0UkTyvDtg0E3wtHYchh4ydNryiySN33QjaiCeDw+ 6tfX/P5dPUwiekUcRCWRl5laLzKqCdu3G6u+sPWrI54hF+7lnJbkNXDK+63BjxYZ1bYoCDCZ8bSEx iLZDnylKw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lf7W1-0082f4-9W; Fri, 07 May 2021 20:56:05 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lf7Ve-0082cw-JG for linux-arm-kernel@desiato.infradead.org; Fri, 07 May 2021 20:55:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender :Reply-To:Content-Type:Content-ID:Content-Description; bh=JjJoLbgf5BX/TlG1bI+Kk/boPZKnP4KZr4LpucGo6G0=; b=Umn4z+cVuaK/Ucet87BVQQ5kYm 1uc6nQ++rP7tzIU010GwuuEg8dGt6P23wuSWsKzfU5oLnBIjHVNwCRQKGwDs9Me5HBcgYD5f8oiKZ 0pY7NtGmYKLpQdpQzIcAKTf2pEU8DuTfqwwANiqKH0M/QEyPCOQ0Jo/kKWHrqCmUkdDkEmIaavzqr p/sQcOSh27XbE5NTgluIiZYIv80TPG+/R4jSkFFUoOTlUlwIqbsd8KIRZw4gbu5RHY/pxEMZvupKk BU0qrvV9J2gEhDQzjt4NhH2DJKFyXissi9UjQP+Zeg+T9l4yk9NUMWa7m9LxqUi4LE22iDDwd1HOM L11rzu4w==; Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lf7Vb-007BBB-SV for linux-arm-kernel@lists.infradead.org; Fri, 07 May 2021 20:55:41 +0000 Received: by mail-pj1-x102b.google.com with SMTP id gq14-20020a17090b104eb029015be008ab0fso6160595pjb.1 for ; Fri, 07 May 2021 13:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=JjJoLbgf5BX/TlG1bI+Kk/boPZKnP4KZr4LpucGo6G0=; b=DFII9SqWyqrDU9lhR3hYRV3l31VXnZO90h4xMn9cSkQqpXilJjFYmS44q9qHsxCuRt q5BaeNKIvn2kvWqzxsiWNybBlHP1OesIS/6xJKcf5t/SlBCjdY/doLp6V4/LIfoTvjS+ Ci6+DW0Zojpe3elbVT9wXx6Wx2XmyBU7gk/Fw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=JjJoLbgf5BX/TlG1bI+Kk/boPZKnP4KZr4LpucGo6G0=; b=f1Z8xxI1ZQw66sL7Dk+FYRnVSkA6WJfVReKHR8sfmEWl9ynX6e2N+bNG7Hh8vQ/52B 4T3jq+bk5wAy8bgRRGkDKuGAaAUBqEAcmX95ERFhuUimp2D3EPp8oiZuitGurON0XNjc hqeqrAoT7B/s80VlZWRhxSkcSrLMaSDyuMwgT05Hl/8KY6tbanJzpqIJA6005hM0hz9P f/Hylwwby+jpisYK/UCvUFO334HI7DVrdVbHfOSFjoFhwHqUo5Tcp9ScJus2rwxSCHSu aupmrrVKVPlxvKAEkyW7IHpQYqefSCeepEeVcM66pIblJSqf1sy+m0fAOMsu8uTtwBoH sfjg== X-Gm-Message-State: AOAM5322aeUJwmI0qFeFdRGcnhnDGM037Deprk62aiCtPn2jMWERJl07 gmYnQbwR3lnYyBtTDHGNGu7T8A== X-Google-Smtp-Source: ABdhPJyup01PkZ3ncI/RlK/Tat7KsSkKwUimMvrvTTRMPZsXwtUPvKcfNKmieitwxrPoVXhlbByzEQ== X-Received: by 2002:a17:90a:6c62:: with SMTP id x89mr25313809pjj.213.1620420939064; Fri, 07 May 2021 13:55:39 -0700 (PDT) Received: from tictac2.mtv.corp.google.com ([2620:15c:202:201:3c7e:d35:3a19:632f]) by smtp.gmail.com with ESMTPSA id ge4sm13161565pjb.49.2021.05.07.13.55.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 May 2021 13:55:38 -0700 (PDT) From: Douglas Anderson To: Catalin Marinas , Will Deacon Cc: Nick Desaulniers , Seth LaForge , Ricky Liang , Douglas Anderson , Alexander Shishkin , Arnaldo Carvalho de Melo , Ingo Molnar , Jiri Olsa , Mark Rutland , Namhyung Kim , Nathan Chancellor , Peter Zijlstra , clang-built-linux@googlegroups.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org Subject: [PATCH 2/3] arm64: perf: Improve compat perf_callchain_user() for clang leaf functions Date: Fri, 7 May 2021 13:55:12 -0700 Message-Id: <20210507135509.2.Ib54050e4091679cc31b04d52d7ef200f99faaae5@changeid> X-Mailer: git-send-email 2.31.1.607.g51e8a6a459-goog In-Reply-To: <20210507205513.640780-1-dianders@chromium.org> References: <20210507205513.640780-1-dianders@chromium.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210507_135539_947956_8F3DF12D X-CRM114-Status: GOOD ( 33.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org It turns out that even when you compile code with clang with "-fno-omit-frame-pointer" that it won't generate a frame pointer for leaf functions (those that don't call any sub-functions). Presumably clang does this to reduce the overhead of frame pointers. In a leaf function you don't really need frame pointers since the Link Register (LR) is guaranteed to always point to the caller. Clang's optimization here is a bit of a pain for us, though. A human might have an easy time figuring out if a function is a leaf function or not and in theory we could have a way to lookup a given PC to find out if it's in a leaf function. Unfortunately we haven't passed the Turing test and we don't have any auxiliary data to help us. If we just ignore this problem then the end result isn't terrible. It just turns out that the _callers_ of leaf functions won't be logged. I guess that's OK, but it could lead to some confusing traces. Another option (the one proposed in this patch) is to always log the first LR when we're tracing, assuming that we hadn't already decided to log it for some other reason. Good things about always logging the LR: * clang leaf functions are handled better. * if PC is right at the start of a function (even on non-clang) it's handled better. Bad things about the LR: * We could log a "bogus" PC in the trace. I believe that the most common "bogus" PC that would be logged would be a PC somewhere in the top function being traced. As an example, if we have this function: non_leaf(): 1. Setup the frame pointer 2. Call example() 3. Do something slow 4. Do something else slow 5. Call example2() 6. Return If the PC was in the middle of "Do something else slow" and then we tried to trace, our stack trace would look like this: Top: a) A PC in the middle of "Do something else slow". b) The return address that example() used, probably in "Do something slow" c) The caller of non_leaf() Specifically you can see that there would be two PCs logged for non_leaf(). To me it feels like this is a net-win. It also should be noted that the consumer of our trace records probably _does_ have more information than we do. It could fairly easily ignore this info. Signed-off-by: Douglas Anderson --- arch/arm64/kernel/perf_callchain.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/arch/arm64/kernel/perf_callchain.c b/arch/arm64/kernel/perf_callchain.c index e5ce5f7965d1..b3cd9f371469 100644 --- a/arch/arm64/kernel/perf_callchain.c +++ b/arch/arm64/kernel/perf_callchain.c @@ -326,6 +326,20 @@ static void compat_perf_callchain_user(struct perf_callchain_entry_ctx *entry, while ((entry->nr < entry->max_stack) && fp && !(fp & 0x3)) { err = compat_perf_trace_1(&fp, &pc, leaf_lr); + /* + * If this is the first trace and it didn't find the LR then + * let's throw it in the trace first. This isn't perfect but + * is the best we can do for handling clang leaf functions (or + * the case where we're right at the start of the function + * before the new frame has been pushed). In the worst case + * this can cause us to throw an extra entry that will be some + * location in the same function as the PC. That's not + * amazing but shouldn't really hurt. It seems better than + * throwing away the LR. + */ + if (leaf_lr && leaf_lr != pc) + perf_callchain_store(entry, leaf_lr & ~BIT(0)); + /* Bail out on any type of error */ if (err) break; -- 2.31.1.607.g51e8a6a459-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel