From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Sasha Levin <sashal@kernel.org>
Cc: Matthieu Baerts <matttbe@kernel.org>,
"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Carlos Llamas <cmllamas@google.com>,
Luca Ceresoli <luca.ceresoli@bootlin.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] decode_stacktrace: Support caller address decoding
Date: Fri, 6 Mar 2026 09:31:29 +0900 [thread overview]
Message-ID: <20260306093129.fa5a93ce9cd0b1a8ece0d532@kernel.org> (raw)
In-Reply-To: <aanr20_WwRhJc8v8@laps>
On Thu, 5 Mar 2026 15:47:23 -0500
Sasha Levin <sashal@kernel.org> wrote:
> 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
OK, let's make it the default behavior.
>
> >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.
OK. In case this is an issue, I'll add an option to decode the return address.
Thank you,
>
> --
> Thanks,
> Sasha
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
prev parent reply other threads:[~2026-03-06 0:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-05 16:52 [PATCH v2] decode_stacktrace: Support caller address decoding Masami Hiramatsu (Google)
2026-03-05 17:05 ` Matthieu Baerts
2026-03-05 20:47 ` Sasha Levin
2026-03-06 0:31 ` Masami Hiramatsu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260306093129.fa5a93ce9cd0b1a8ece0d532@kernel.org \
--to=mhiramat@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cmllamas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.ceresoli@bootlin.com \
--cc=matttbe@kernel.org \
--cc=sashal@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.