I have a memory that there is a mode we can put the runtime into where it will log or panic if C code ends up on the Go stack. Is that true? Is such a thing possible ?
On Aug 20, 2014 8:48 PM, "brainman" <alex.b...@gmail.com> wrote:
> I am trying to convert syscall_windows.goc. The file belongs to "syscall" package, not "runtime". I can move that file to "syscall", but it uses some internal runtime types, variables and functions. How do you propose I approach that? asm?
i think the only way to go is to move it to syscall, write in Go that calls assembly forwarding function (just jmp, don't use multiple files for each arch., use #ifdef GOARCH_arm and #define JMP B) to the runtime internal functions.
On Aug 21, 2014 12:38 AM, "brainman" <alex.b...@gmail.com> wrote:
> > ... use #ifdef GOARCH_arm and #define JMP B)
> care to point me to an example file?
i just realized that we don't have windows/arm support atm, but anyway, here is one example:
it builds on all three supported architectures (not power64 though, because it uses BR, but don't worry about power64 now)
On Aug 21, 2014 1:29 AM, "sanjay.m" <balas...@gmail.com> wrote:
> Thanks for the example; I am having the same problem with rdebug.goc (it declares symbols for runtime/debug, and uses runtime internal functions).
> To clarify, if the runtime-internal function is a Go function and the function take an argument, does the assembly stub still say "NOSPLIT,$0"?
> I ask because the NOSPLIT docs seem to say that the NOSPLIT-ted function's frame needs space for all called functions, but I feel like that isn't true if a called function does the stack split check in its own preamble.
it's ok for nosplit function to split stack function.
On Aug 21, 2014 10:44 AM, "'Dmitry Vyukov' via golang-dev" <golan...@googlegroups.com> wrote:
> On Wed, Aug 20, 2014 at 9:31 PM, Keith Randall <k...@google.com> wrote:
> >> Is there anything special about calling Go code on g0 stack long-term?
> > I have a vision of a strict separation, Go code only on the G stack and C
> > code only on the M stack (and a few assembly routines, like memmove, allowed
> > on both). But that's harder and won't happen for 1.4. In particular the Go
> > malloc code runs on the M stack right now.
> > While there is Go code on the M stack, we do have to ensure that that Go
> > code uses bounded stack.
> Humm... I though that we want to get rid of C compiler altogether.
i believe that's still the plan.
russ suggested that we might be able to use his c2go to convert the remaining c code, but we're not there yet.
Removing a C function from the G stack can be done in a few ways: