From: Ian Lance Taylor <iant@golang.org>
To: Matthias Klose <doko@ubuntu.com>
Cc: Cherry Zhang <cherryyz@google.com>,
gcc-patches <gcc-patches@gcc.gnu.org>,
gofrontend-dev@googlegroups.com
Subject: Re: [gofrontend-dev] Re: libgo patch committed: Add precise stack scan support
Date: Tue, 11 Dec 2018 20:51:00 -0000 [thread overview]
Message-ID: <CAOyqgcVZWoiUpbrYb4KL2bLPqzoLXbugMXejdmvgRA7cj-Xt5w@mail.gmail.com> (raw)
In-Reply-To: <75551ca3-e964-cdfa-0a65-2f9b1b34fcb7@ubuntu.com>
On Tue, Dec 11, 2018 at 6:52 AM Matthias Klose <doko@ubuntu.com> wrote:
>
> On 10.12.18 16:54, Cherry Zhang wrote:
> > On Mon, Dec 10, 2018 at 1:41 AM Matthias Klose <doko@ubuntu.com> wrote:
> >
> >> On 06.12.18 00:09, Ian Lance Taylor wrote:
> >>> This libgo patch by Cherry Zhang adds support for precise stack
> >>> scanning to the Go runtime. This uses per-function stack maps stored
> >>> in the exception tables in the language-specific data area. The
> >>> compiler needs to generate these stack maps; currently this is only
> >>> done by a version of LLVM, not by GCC. Each safepoint in a function
> >>> is associated with a (real or dummy) landing pad, and its "type info"
> >>> in the exception table is a pointer to the stack map. When a stack is
> >>> scanned, the stack map is found by the stack unwinding code.
> >>>
> >>> For precise stack scan we need to unwind the stack. There are three
> >> cases:
> >>>
> >>> - If a goroutine is scanning its own stack, it can unwind the stack
> >>> and scan the frames.
> >>>
> >>> - If a goroutine is scanning another, stopped, goroutine, it cannot
> >>> directly unwind the target stack. We handle this by switching
> >>> (runtime.gogo) to the target g, letting it unwind and scan the stack,
> >>> and switch back.
> >>>
> >>> - If we are scanning a goroutine that is blocked in a syscall, we send
> >>> a signal to the target goroutine's thread, and let the signal handler
> >>> unwind and scan the stack. Extra care is needed as this races with
> >>> enter/exit syscall.
> >>>
> >>> Currently this is only implemented on GNU/Linux.
> >>>
> >>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
> >>> to mainline.
> >>
> >> this broke the libgo build on ARM32:
> >>
> >> ../../../src/libgo/runtime/go-unwind.c: In function
> >> 'scanstackwithmap_callback':
> >> ../../../src/libgo/runtime/go-unwind.c:754:18: error: '_URC_NORMAL_STOP'
> >> undeclared (first use in this function)
> >> 754 | return _URC_NORMAL_STOP;
> >> | ^~~~~~~~~~~~~~~~
> >> ../../../src/libgo/runtime/go-unwind.c:754:18: note: each undeclared
> >> identifier
> >> is reported only once for each function i
> >> t appears in
> >> ../../../src/libgo/runtime/go-unwind.c: In function
> >> 'probestackmaps_callback':
> >> ../../../src/libgo/runtime/go-unwind.c:802:10: error: '_URC_NORMAL_STOP'
> >> undeclared (first use in this function)
> >> 802 | return _URC_NORMAL_STOP;
> >> | ^~~~~~~~~~~~~~~~
> >> ../../../src/libgo/runtime/go-unwind.c:803:1: warning: control reaches end
> >> of
> >> non-void function [-Wreturn-type]
> >> 803 | }
> >> | ^
> >> make[6]: *** [Makefile:1474: runtime/go-unwind.lo] Error 1
> >> make[6]: Leaving directory
> >> '/<<PKGBUILDDIR>>/build/arm-linux-gnueabihf/libgo'
> >>
> >>
> > Hell Matthias,
> >
> > Thank you for the report. And sorry about the breakage. Does
> > https://go-review.googlesource.com/c/gofrontend/+/153417 (or the patch
> > below) fix ARM32 build? I don't have an ARM32 machine at hand to test.
>
> this fixes the build.
>
> currently running the testsuite, almost every test case core dumps on
> arm-linux-gnueabihf
I committed Cherry's patch to trunk, since it looks reasonable to me.
Cherry, Matthias, let me know if you figure out why programs are
failing.
Ian
next prev parent reply other threads:[~2018-12-11 20:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-05 23:10 Ian Lance Taylor
2018-12-07 10:07 ` Rainer Orth
2018-12-07 14:23 ` Ian Lance Taylor
2018-12-07 15:15 ` [gofrontend-dev] " Cherry Zhang via gcc-patches
2018-12-10 6:41 ` Matthias Klose
2018-12-10 15:54 ` [gofrontend-dev] " Cherry Zhang via gcc-patches
2018-12-11 14:52 ` Matthias Klose
2018-12-11 20:51 ` Ian Lance Taylor [this message]
2018-12-11 21:02 ` Cherry Zhang via gcc-patches
2018-12-12 0:03 ` Matthias Klose
2018-12-12 16:10 ` Cherry Zhang via gcc-patches
2018-12-12 23:27 ` Ian Lance Taylor
2018-12-19 3:24 ` Matthias Klose
2018-12-26 20:42 ` Cherry Zhang via gcc-patches
2018-12-27 9:42 ` Ian Lance Taylor
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=CAOyqgcVZWoiUpbrYb4KL2bLPqzoLXbugMXejdmvgRA7cj-Xt5w@mail.gmail.com \
--to=iant@golang.org \
--cc=cherryyz@google.com \
--cc=doko@ubuntu.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gofrontend-dev@googlegroups.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 read-only IMAP folder(s) and NNTP newsgroup(s).