From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 42B313858C5E for ; Thu, 23 Feb 2023 10:25:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 42B313858C5E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from r6.localdomain (82-217-174-174.cable.dynamic.v4.ziggo.nl [82.217.174.174]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 7770430067D6; Thu, 23 Feb 2023 11:25:53 +0100 (CET) Received: by r6.localdomain (Postfix, from userid 1000) id 32177340251; Thu, 23 Feb 2023 11:25:53 +0100 (CET) Message-ID: Subject: Re: A scenario where Perf cannot unwind the user stack by dwarf with libdw.so From: Mark Wielaard To: "liuxu (AJ)" Cc: "elfutils-devel@sourceware.org" , "Wangqiangdong(Frank, IAS)" , "zhangjianwei (D)" , dingzhuang Date: Thu, 23 Feb 2023 11:25:53 +0100 In-Reply-To: <20230216224817.GG6028@gnu.wildebeest.org> References: <88c25e0709834e1a816630c944377640@huawei.com> <20230216224817.GG6028@gnu.wildebeest.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) MIME-Version: 1.0 X-Spam-Status: No, score=-3029.7 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, On Thu, 2023-02-16 at 23:48 +0100, Mark Wielaard wrote: > On Mon, Feb 13, 2023 at 01:44:39AM +0000, liuxu (AJ) via Elfutils-devel w= rote: > > I am failing to unwind the user stack with libdw on Ubuntu 18.04 > > arm64 environment, the toolchain used is clang 12.0.1. form the > > unwinding process, I found that the pc value passing to handle_cfi > > is 0x760, which is 0x10000 offset from the corresponding cfi address > > 0x10760. > >=20 > > Futher analysis show that the bias calculated in > > __libdwfl_elf_address_range for ET_DYN type pick the first PT_LOAD > > segment, not the segment corresponds to code segment. So the bias > > result is wrong in current situation. >=20 > I have some problem replicating this because I don't have the same > toolchain and don't know enough about perf to know how to replicate. We have discussed this a bit more offlist. But I still haven't been able to replicate this issue. It seems to depend on a couple of things I don't fully understand, clang, lld, musl, PIE executables, whether the fallback frame based unwinder can/is used, etc. I am hoping someone can sent me a binary to investigate. Thanks, Mark