On Wed, Jan 14, 2015 at 4:33 PM, Phil Eaton wrote:
Thanks for that! That's really helpful about the plans for the future but
not so helpful describing why the limitations are currently the way they
are. I.e. what design decisions led to this point. I'm also interested in
The Go runtime expects to be invoked at the start of the process. It
reads the auxiliary vector passed in by the kernel. It sets up signal
handlers. It allocates large chunks of contiguous memory. It
allocates thread local storage slots.
So if I wanted to start working on a substitute runtime by (e.g.) defining
the symbols I'm missing (like __go_new). How can I go about finding out more
information? In particular what is this __go_new function? I grepped for it
in the goland source and didn't find anything. If I could correctly define
these symbols and link against them in my process, couldn't I get this
I've included the shared object file that links against a go object file
generated from libtool and gccgo. Feel free to find the __go_new reference
I'm referring to. I'm assuming this is a memory management function?
Admittedly things are a little different with gccgo. With gccgo it is
more feasible to start the program as a C program. Earlier you
mentioned rt0_linux_amd64.s, but that is part of the gc toolchain, not
With gccgo, look at main in libgo/runtime/go-main.c and runtime_main
in libgo/runtime/proc.c. If you can arrange to have all those steps
occur up to the point of the call to main_main, then you have a
fighting chance of having it work. I've never tried it and there may
be serious problems.
__go_new is defined in libgo/runtime.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.