From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E00BD347508 for ; Thu, 5 Mar 2026 20:47:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772743645; cv=none; b=fKZoYm/u7pyj2s4z170+xz16vbUPPPbC5yFJ31nyIoVp1EbKGTj0yA/Cl8qEZY9+oRk1gqNrpGnG5qTrDkFzgZPjNrGqmI0RnXBoMIH0TqCd2WtoUuLib24Rf2JEWOfXqhI3Q9zzo9sQ9LdtMvPVNjg8PcfAwBnlBlh42473PAU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772743645; c=relaxed/simple; bh=JogqlvTd0j1GBekPilKoNW/78juUXfCAr/Gk/j5cbAE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bn+yO7IPfHVg5+2or12x2LQ1M29mB1xSg/u6l+UyqO3y52vMFFd/ijA+SeLvbIbJkignx2xFVLAPX0jdGyC9V3mp+aJWne6ELE6T+Rm2zf6TUoz+OND2VcNKbkSYNhPREDRszrn6B308dCKT5R2OEZqJe8FPAcHdSqhKgr6ElAM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=u8fwRVoO; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="u8fwRVoO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37DF8C116C6; Thu, 5 Mar 2026 20:47:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772743645; bh=JogqlvTd0j1GBekPilKoNW/78juUXfCAr/Gk/j5cbAE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=u8fwRVoO0xNA/Gy7QFJi2/ywY6yBsUGFXb/E2d0Y4464Cdz4YXVDM8+lZFeFOZlJ8 OBeahhRdsWLLiKrSyXaZaR0dAONENVDhqbHDl1z68HbZpJKN7XVklW6kjQ6qMRDXvg If+oOyluCotuReGjyIUr8JVGYL8GEMTRhYyM2U/050D7CnfZXMLVuxiPNfeRPOiGpt ch2gzgF50/bvEn4ucI0nm9K9sll/4rvf+Rl/FTd9wZ3HRdKoZBSulFH/LRJGecy3CN tKFDlmqJUsaloLGQmVGjRmwc4uT9oQD8yx7p63OGYmUgqJ4pUmKK866fmeHAdEz34g b2k0FQukvNenQ== Date: Thu, 5 Mar 2026 15:47:23 -0500 From: Sasha Levin To: Matthieu Baerts Cc: "Masami Hiramatsu (Google)" , Andrew Morton , Carlos Llamas , Luca Ceresoli , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] decode_stacktrace: Support caller address decoding Message-ID: References: <177272956276.1018623.6026552620206046640.stgit@mhiramat.tok.corp.google.com> <7f47295b-803b-4d17-900f-8e19f2931407@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <7f47295b-803b-4d17-900f-8e19f2931407@kernel.org> On Thu, Mar 05, 2026 at 06:05:59PM +0100, Matthieu Baerts wrote: >Hi Masami, > >Thank you for the new version, and your previous reply! > >On 05/03/2026 17:52, Masami Hiramatsu (Google) wrote: >> Add -c option to decodecall address instead of the return address. >> With this option, it decodes the line info 1byte before the return >> address which will be the call(branch) instruction address. >> If the return address is a symbol address, it falls back to >> decoding the return address. > >>From what I got from Sasha, this "addr-1" trick seems quite common. Why >not using this new feature by default, and having an option to disable it? +1 >Or no option if someone can validate the new behaviour on architectures >which have these delay slots you mentioned? I didn't think that delay slots were an issue because architectures with delay slots handle their stack unwinding and return address adjustment in their own arch-specific code before it ever reaches the script. -- Thanks, Sasha