aboutsummaryrefslogtreecommitdiff
path: root/src/path/filepath
diff options
context:
space:
mode:
authorDavid Chase <drchase@google.com>2025-02-18 17:34:24 -0500
committerDavid Chase <drchase@google.com>2025-02-19 08:27:06 -0800
commit9ddeac30b5c41f223564e1dedef3095a5a909cb9 (patch)
treef0db5d7e6aa50c7a00bd7a1f993bbab438def320 /src/path/filepath
parent4267fd389e941cf197cc3890cc42e474866c0d30 (diff)
downloadgo-9ddeac30b5c41f223564e1dedef3095a5a909cb9.tar.xz
cmd/compile, runtime: use deferreturn as target PC for recover from deferrangefunc
The existing code for recover from deferrangefunc was broken in several ways. 1. the code following a deferrangefunc call did not check the return value for an out-of-band value indicating "return now" (i.e., recover was called) 2. the returned value was delivered using a bespoke ABI that happened to match on register-ABI platforms, but not on older stack-based ABI. 3. the returned value was the wrong width (1 word versus 2) and type/value(integer 1, not a pointer to anything) for deferrangefunc's any-typed return value (in practice, the OOB value check could catch this, but still, it's sketchy). This -- using the deferreturn lookup method already in place for open-coded defers -- turned out to be a much-less-ugly way of obtaining the desired transfer of control for recover(). TODO: we also could do this for regular defer, and delete some code. Fixes #71675 Change-Id: If7d7ea789ad4320821aab3b443759a7d71647ff0 Reviewed-on: https://go-review.googlesource.com/c/go/+/650476 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Diffstat (limited to 'src/path/filepath')
0 files changed, 0 insertions, 0 deletions