From: Richard Henderson <richard.henderson@linaro.org>
To: Matheus Tavares Bernardino <quic_mathbern@quicinc.com>,
ltaylorsimpson@gmail.com
Cc: bcain@quicinc.com, qemu-devel@nongnu.org,
quic_mliebel@quicinc.com, e.emanuelegiuseppe@gmail.com
Subject: Re: [PATCH] Hexagon: move GETPC() calls to top level helpers
Date: Wed, 5 Jul 2023 15:46:18 +0200 [thread overview]
Message-ID: <5a6ebc83-3f10-8cae-8fe2-478379d8429b@linaro.org> (raw)
In-Reply-To: <20230705124520.2693489-1-quic_mathbern@quicinc.com>
On 7/5/23 14:45, Matheus Tavares Bernardino wrote:
>> Taylor <ltaylorsimpson@gmail.com> wrote:
>> Note that check_noshuf calls HELPER(probe_noshuf_load) and
>> HELPER(commit_store). Both of those call GETPC() from within. So, you'll
>> need to pull the contents into separate functions that take ra as an
>> argument.
>
> Ah, good point. It was my understanding that, in case of a memory
> exception in one of those nested helper calls, the GETPC() we would want
> to use for unwinding was the one from the most recent helper. I'm still
> trying to wrap my head around these concepts, though, so I might have
> misunderstood it. Is this not the case?
No, it is not the case.
GETPC fetches the return address from the current function.
The unwinder which uses this value needs the return address *into* the generated code.
Therefore the HELPER function that is directly called from generated code is the place at
which GETPC must be used, and nowhere else. The corollary is that one HELPER should avoid
calling another HELPER, Just In Case -- use separate intermediate functions instead, as
Taylor suggests above.
r~
prev parent reply other threads:[~2023-07-05 13:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-03 21:49 [PATCH] Hexagon: move GETPC() calls to top level helpers Matheus Tavares Bernardino
2023-07-03 21:52 ` Brian Cain
2023-07-04 20:34 ` Matheus Tavares Bernardino
2023-07-04 22:00 ` ltaylorsimpson
2023-07-05 12:45 ` Matheus Tavares Bernardino
2023-07-05 13:46 ` Richard Henderson [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=5a6ebc83-3f10-8cae-8fe2-478379d8429b@linaro.org \
--to=richard.henderson@linaro.org \
--cc=bcain@quicinc.com \
--cc=e.emanuelegiuseppe@gmail.com \
--cc=ltaylorsimpson@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=quic_mathbern@quicinc.com \
--cc=quic_mliebel@quicinc.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).