Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp1156989pxb; Wed, 6 Apr 2022 10:03:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxyFqQiwl0nAhcV0d5BA4TM6BorbK6iDspEtotbue4ZSDXMUjt7mmOxrORTjNlTXcjGa/t8 X-Received: by 2002:a17:903:2441:b0:156:cd2c:c935 with SMTP id l1-20020a170903244100b00156cd2cc935mr9456519pls.121.1649264635917; Wed, 06 Apr 2022 10:03:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649264635; cv=none; d=google.com; s=arc-20160816; b=tKwZfprVOt5zlVUAlCQySWdZIBd1LP7tMWcRgFmwpM1TEPbpFid5TfTjTiPylN0gm6 ziZcHLfu4vzM3Z0ust4yliH9TYOEyia/5NjQ96qzWebIdtvRcwuiJuAURIR1rYaQ2nFm xRwYzA46KpMxydI6hddtBUG57ldTxiYS2g3Mdxs2oYeD22h4c+FltBRd806CXhyOAmJ3 HmDVyEgnqB055Odi3nXGNYoUhh6CiFfSpriZ1lrxgQeUYVhrZmnYd7TzNX3J4Vl5SDE7 Q7ub8T5+tU3U6YY8Q+YlraM0PBIH9R9zPPDW7XQu32qDNz5qQ6u2H8rV38jXA6nNqaC/ lEqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:references :cc:to:from:content-language:subject:user-agent:mime-version:date :message-id; bh=vf34lGq/qqeriwBbst3U6lGrJyHhAxojlA5gRRmv/b0=; b=ptFjb44aDkV/StEkgCzF9c3P+gBTlhDBVXprx4alpKD1nC4NlKKaycv3fLSewcqa7k iAq5CMM5VgGDSV3bj4s7iO1logklgZ8ItSNi1wYRWC8mRiFdMxHnT/Q3q/5vWZnexCkT gucLBoQsUts7QSlPg70p2VzCzc3nveVS1r70b6pjBExoeOYxYcpkByZ7uH3Hl+55QvKv H1hsB+MlFht/Va5d66V/Uw3PUEH04BQWxxuD6GR7NoMEdzCWktSoWgcJZXsl+HUaYIoK zNYMz6u1fPYc6ib8/h4kd8Eeh0uUBqNqVFksWCK7KV/VKbfBBHOx6dzgT/ZIgZasu0gg A2UA== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id i67-20020a625446000000b004fae7081aa7si15310323pfb.370.2022.04.06.10.03.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 10:03:55 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C7C83EDF0D; Wed, 6 Apr 2022 09:44:52 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238110AbiDFQqn (ORCPT + 99 others); Wed, 6 Apr 2022 12:46:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56196 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238074AbiDFQqE (ORCPT ); Wed, 6 Apr 2022 12:46:04 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E850E322815; Wed, 6 Apr 2022 08:00:20 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D26C712FC; Wed, 6 Apr 2022 08:00:19 -0700 (PDT) Received: from [10.57.10.15] (unknown [10.57.10.15]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CFE863F73B; Wed, 6 Apr 2022 08:00:18 -0700 (PDT) Message-ID: <718ca801-b9db-ac33-d224-9c569aab7446@arm.com> Date: Wed, 6 Apr 2022 16:00:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: perf tool: About "perf arm64: Inject missing frames when using 'perf record --call-graph=fp'" Content-Language: en-US From: James Clark To: John Garry , alexandre.truong@arm.com Cc: linux-perf-users@vger.kernel.org, "jolsa@kernel.org >> Jiri Olsa" , german.gomez@arm.com, Linux Kernel Mailing List , Arnaldo Carvalho de Melo References: <5f1d8b3f-0afa-2724-4ff1-f061939c68c5@huawei.com> <2dc4266f-02b1-0937-a884-dfa037cc7ffd@arm.com> In-Reply-To: <2dc4266f-02b1-0937-a884-dfa037cc7ffd@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/04/2022 10:08, James Clark wrote: > > > On 05/04/2022 15:04, John Garry wrote: >> Hi Alexandre, >> >> I notice that with commit b9f6fbb3b2c2 ("perf arm64: Inject missing frames when using 'perf record --call-graph=fp'") that I get messages spewing the console when running perf record+report, as below: >> >> john@ubuntu:~/linux$sudo tools/perf/perf record -ag fio null12.fio >> john@ubuntu:~/linux$sudo tools/perf/perf report > report >> unwind: can't read reg 29 >> unwind: can't read reg 29 >> unwind: can't read reg 29 >> unwind: can't read reg 29 >> ... >> >> Do you know the possible cause? I haven't checked... > > Hi John, > > I'm going to look into this today. I expect the cause is because we only record > the link register for this change and then do a best effort unwind to see if > we can get the return address just from that. So I don't think this is a major issue, > probably the outcome will be that I mask any of these errors just for this call > to libunwind that we added. The other main call to libunwind should still print > these errors. > > One thing that is interesting is why we didn't see this when we were testing > the patch before, and we've also found it a little bit difficult to reproduce here. > So there might be more to it than just masking the error, but I'm not sure yet. > > Either way, I don't expect that any unwinding is broken, just that it's > printing an annoying message. > In my case it was showing the error because I'd installed libc debug symbols which explains why we might have missed it before. Also it's looking for the frame pointer register which doesn't make sense to save because that would be used to look into the stack which isn't recorded. So for that reason I think suppressing the error is the best thing to do. I've sent "[PATCH] perf: Don't show unwind error messages when augmenting frame pointer stack" > James > >> >> Thanks, >> john