On Tue, Dec 11, 2018 at 3:51 PM Ian Lance Taylor <i...@golang.org> wrote:
> On Tue, Dec 11, 2018 at 6:52 AM Matthias Klose <d...@ubuntu.com> wrote: > > > > On 10.12.18 16:54, Cherry Zhang wrote: > > > On Mon, Dec 10, 2018 at 1:41 AM Matthias Klose <d...@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. > > Thank you. I don't know for the moment. I'm trying to find an ARM32 machine so I can test. Matthias, is it convenient for you to share a stack trace for the failing programs? That would be very helpful. Thanks!
