From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82596 invoked by alias); 12 Dec 2018 16:10:18 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 82579 invoked by uid 89); 12 Dec 2018 16:10:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-34.9 required=5.0 tests=BAYES_00,ENV_AND_HDR_SPF_MATCH,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=ham version=3.3.2 spammy=H*f:sk:ced1bf9, H*f:sk:75551ca, wreturn-type, Currently X-HELO: mail-yw1-f41.google.com Received: from mail-yw1-f41.google.com (HELO mail-yw1-f41.google.com) (209.85.161.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Dec 2018 16:10:12 +0000 Received: by mail-yw1-f41.google.com with SMTP id t13so7169229ywe.13 for ; Wed, 12 Dec 2018 08:10:11 -0800 (PST) MIME-Version: 1.0 References: <75551ca3-e964-cdfa-0a65-2f9b1b34fcb7@ubuntu.com> <76c6e133-f842-2ba6-1c26-911633941937@ubuntu.com> In-Reply-To: <76c6e133-f842-2ba6-1c26-911633941937@ubuntu.com> From: "Cherry Zhang via gcc-patches" Reply-To: Cherry Zhang Date: Wed, 12 Dec 2018 16:10:00 -0000 Message-ID: Subject: Re: [gofrontend-dev] Re: libgo patch committed: Add precise stack scan support To: doko@ubuntu.com Cc: Ian Taylor , gcc-patches@gcc.gnu.org, gofrontend-dev@googlegroups.com Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-12/txt/msg00832.txt.bz2 Thank you, Matthias! >From the log, essentially all the tests aborted. The only place the new code can cause abort on all programs that I can think of is in the runtime startup code, probestackmaps, which calls value_size, which aborts due to an unhandled case. I haven't been able to try out on an ARM machine, but I managed to cross-compile a Go program and visually inspect the exception table. The type table's encoding is DW_EH_PE_absptr, which is indeed not handled, which will cause abort. I send https://go-review.googlesource.com/c/gofrontend/+/153857 (also as below). Hopefully this will fix the problem. Thanks, Cherry diff --git a/libgo/runtime/go-unwind.c b/libgo/runtime/go-unwind.c index c44755f9..f4bbfb60 100644 --- a/libgo/runtime/go-unwind.c +++ b/libgo/runtime/go-unwind.c @@ -318,6 +318,8 @@ value_size (uint8_t encoding) case DW_EH_PE_sdata8: case DW_EH_PE_udata8: return 8; + case DW_EH_PE_absptr: + return sizeof(uintptr); default: break; } On Tue, Dec 11, 2018 at 7:03 PM Matthias Klose wrote: > On 11.12.18 22:01, Cherry Zhang wrote: > > On Tue, Dec 11, 2018 at 3:51 PM Ian Lance Taylor > wrote: > > > >> On Tue, Dec 11, 2018 at 6:52 AM Matthias Klose wrote: > >>> > >>> On 10.12.18 16:54, Cherry Zhang wrote: > >>>> On Mon, Dec 10, 2018 at 1:41 AM Matthias Klose > >> 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 > >>>>> '/<>/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! > > I'll do a local build this weekend. For now you find the build log at > > https://launchpad.net/ubuntu/+source/gcc-snapshot/1:20181210-0ubuntu1/+build/15759748 >