public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Cherry Zhang via gcc-patches" <gcc-patches@gcc.gnu.org>
To: doko@ubuntu.com
Cc: Ian Taylor <iant@golang.org>,
	gcc-patches@gcc.gnu.org, 	gofrontend-dev@googlegroups.com
Subject: Re: [gofrontend-dev] Re: libgo patch committed: Add precise stack scan support
Date: Mon, 10 Dec 2018 15:54:00 -0000	[thread overview]
Message-ID: <CAHpjNS+rDFCTkaTkqLO7bhxkp5kNAjW4WSPsGUQPDmfNkveV+Q@mail.gmail.com> (raw)
In-Reply-To: <ced1bf91-ddc8-bea2-bd15-f6a72c83b296@ubuntu.com>

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.

Thanks,
Cherry

diff --git a/libgo/runtime/go-unwind.c b/libgo/runtime/go-unwind.c
index a1a95585..c44755f9 100644
--- a/libgo/runtime/go-unwind.c
+++ b/libgo/runtime/go-unwind.c
@@ -392,6 +392,12 @@ parse_lsda_header (struct _Unwind_Context *context,
const unsigned char *p,
 #define CONTINUE_UNWINDING return _URC_CONTINUE_UNWIND
 #endif

+#ifdef __ARM_EABI_UNWINDER__
+#define STOP_UNWINDING _URC_FAILURE
+#else
+#define STOP_UNWINDING _URC_NORMAL_STOP
+#endif
+
 #ifdef __USING_SJLJ_EXCEPTIONS__
 #define PERSONALITY_FUNCTION    __gccgo_personality_sj0
 #define __builtin_eh_return_data_regno(x) x
@@ -751,7 +757,7 @@ scanstackwithmap_callback (struct _Unwind_Context
*context, void *arg)
               // TODO: print gp, pc, sp
               runtime_throw ("no stack map");
             }
-          return _URC_NORMAL_STOP;
+          return STOP_UNWINDING;
         }
       case FOUND:
         break;
@@ -799,7 +805,7 @@ probestackmaps_callback (struct _Unwind_Context
*context,

   // Found a stack map. No need to keep unwinding.
   runtime_usestackmaps = true;
-  return _URC_NORMAL_STOP;
+  return STOP_UNWINDING;
 }

 // Try to find a stack map, store the result in global variable
runtime_usestackmaps.

  reply	other threads:[~2018-12-10 15:54 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   ` Cherry Zhang via gcc-patches [this message]
2018-12-11 14:52     ` [gofrontend-dev] " Matthias Klose
2018-12-11 20:51       ` Ian Lance Taylor
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=CAHpjNS+rDFCTkaTkqLO7bhxkp5kNAjW4WSPsGUQPDmfNkveV+Q@mail.gmail.com \
    --to=gcc-patches@gcc.gnu.org \
    --cc=cherryyz@google.com \
    --cc=doko@ubuntu.com \
    --cc=gofrontend-dev@googlegroups.com \
    --cc=iant@golang.org \
    /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).