Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Golang support #522

Closed
6D65 opened this issue Oct 19, 2014 · 7 comments
Closed

Golang support #522

6D65 opened this issue Oct 19, 2014 · 7 comments

Comments

@6D65
Copy link

6D65 commented Oct 19, 2014

Hi,

You probably have been asked this a billion times already, but I can't seem to find the info whether you support Go. I watched some not too new presentations, and there's mentioned that JVM based languages are fully supported, and C to some extent(except exec, fork).

I like the idea of a low overhead cloud OS but carying over 100MB of runtime for the JVM languages is a thing that i would avoid, especially when the OS itself is around 20MB.

Btw, i'm aware that Go is not slim either, but at least it's getting better.

Thanks
@dorlaor
Copy link
Contributor

dorlaor commented Oct 20, 2014

Hi,

We're indeed interested in Go lang. Today we can run it since OSv apps
share the same address space
with the kernel and thus need to be compiled as shared library. This isn't
the case w/ Go.
One way to mitigate it is to move the kernel mapping and let the app start
on virtual addr 0.

On Sun, Oct 19, 2014 at 7:45 PM, 6D65 notifications@github.com wrote:

Hi,

You probably have been asked this a billion times already, but I can't
seem to find the info whether you support Go. I watched some not too new
presentations, and there's mentioned that JVM based languages are fully
supported, and C to some extent(except exec, fork).

I like the idea of a low overhead cloud OS but carying over 100MB of
runtime for the JVM languages is a thing that i would avoid, except when
the OS itself is around 20MB.

Thanks

—
Reply to this email directly or view it on GitHub
#522.

@6D65
Copy link
Author

6D65 commented Oct 21, 2014

Cool, thanks. I guess i'll have to play around with it, and see what can be done.

@penberg
Copy link
Contributor

penberg commented Oct 22, 2014

@6D65 @dorlaor I have some work-in-progress code to support static ELFs (CC @pdziepak):

https://github.com/penberg/osv/commits/static-elf

as well as preliminary support for running Go binaries that use the syscall instruction directly:

https://github.com/penberg/osv/commits/golang

I haven't really had the time to work on them recently but supporting Go under OSv is definitely doable.

@pdziepak
Copy link
Contributor

2014-10-22 12:08 GMT+02:00 Pekka Enberg notifications@github.com:

@6D65 https://github.com/6D65 @dorlaor https://github.com/dorlaor I
have some work-in-progress code to support static ELFs (CC @pdziepak
https://github.com/pdziepak):

https://github.com/penberg/osv/commits/static-elf

as well as preliminary support for running Go binaries that use the
syscall instruction directly:

https://github.com/penberg/osv/commits/golang

I haven't really had the time to work on them recently but supporting Go
under OSv is definitely doable.

There is also a problem with TLS similar to #352, but since in case of
static binaries we have clearly defined all kernel entry/exit points it
wouldn't be very hard to appropriately swap "user" and "kernel" tls in
syscall_entry.

Moving kernel to higher addresses (but still inside first 2GB) seems to be
a good solution that in virtually all cases would prevent kernel-program
address conflict. Obviosuly, the ideal way of doing this would be to move
kernel to the uppermost 2GB and switch memrory code model to "kernel", but
that would make it impossible to link OSv with the static libraries meant
for "normal" executables.

@6D65
Copy link
Author

6D65 commented Oct 24, 2014

Thank you @penberg and @pdziepak i'll definitely give it a try this weekend. Hopefully it's a start of something great.

@nyh nyh mentioned this issue Feb 15, 2015
Closed
@nyh nyh mentioned this issue Aug 21, 2016
Closed
@nyh nyh mentioned this issue Sep 2, 2016
Closed
This was referenced Nov 3, 2016
Closed
Closed
Open
benoit-canet pushed a commit to benoit-canet/osv that referenced this issue Nov 15, 2016
elf/app: Pass argc and argv to library initialization
fc85262 
As explained nicely in golang/go#13492, since 1996
glibc's dlopen() passes argv and a bunch of other
stuff to the initialization functions of shared
objects, while we don't pass any argument
(see object::run_init_funcs()). Golang code
(ref cloudius-systems#522), in particular, assumes it gets argv,
auxv, etc., this way.

Fixes: cloudius-systems#795

Signed-off-by: Benoît Canet <benoit@scylladb.com>
benoit-canet pushed a commit to benoit-canet/osv that referenced this issue Jan 13, 2017
elf/app: Pass argc and argv to library initialization
c93d358 
As explained nicely in golang/go#13492, since 1996
glibc's dlopen() passes argv and a bunch of other
stuff to the initialization functions of shared
objects, while we don't pass any argument
(see object::run_init_funcs()). Golang code
(ref cloudius-systems#522), in particular, assumes it gets argv,
auxv, etc., this way.

Fixes: cloudius-systems#795

Signed-off-by: Benoît Canet <benoit@scylladb.com>
benoit-canet pushed a commit to benoit-canet/osv that referenced this issue Feb 8, 2017
elf/app: Pass argc and argv to library initialization
7ea4bdb 
As explained nicely in golang/go#13492, since 1996
glibc's dlopen() passes argv and a bunch of other
stuff to the initialization functions of shared
objects, while we don't pass any argument
(see object::run_init_funcs()). Golang code
(ref cloudius-systems#522), in particular, assumes it gets argv,
auxv, etc., this way.

Fixes: cloudius-systems#795

Signed-off-by: Benoît Canet <benoit@scylladb.com>
benoit-canet pushed a commit to benoit-canet/osv that referenced this issue Feb 8, 2017
elf/app: Pass argc and argv to library initialization
d9fa636 
As explained nicely in golang/go#13492, since 1996
glibc's dlopen() passes argv and a bunch of other
stuff to the initialization functions of shared
objects, while we don't pass any argument
(see object::run_init_funcs()). Golang code
(ref cloudius-systems#522), in particular, assumes it gets argv,
auxv, etc., this way.

Fixes: cloudius-systems#795

Signed-off-by: Benoît Canet <benoit@scylladb.com>
benoit-canet pushed a commit to benoit-canet/osv that referenced this issue Feb 9, 2017
elf/app: Pass argc and argv to library initialization
fb6e551 
As explained nicely in golang/go#13492, since 1996
glibc's dlopen() passes argv and a bunch of other
stuff to the initialization functions of shared
objects, while we don't pass any argument
(see object::run_init_funcs()). Golang code
(ref cloudius-systems#522), in particular, assumes it gets argv,
auxv, etc., this way.

Fixes: cloudius-systems#795

Signed-off-by: Benoît Canet <benoit@scylladb.com>
nyh added a commit that referenced this issue Feb 12, 2017
@nyh
signals: proper support for sigaltstack() and SA_ONSTACK sigaction flag
bf7fbc3 
When an application gets a SIGSEGV because it overflowed the thread's
stack, it is pointless to try to run a signal handler on the same stack
which has no room to run on. This is why Linux provides a sigaltstack()
function which allows the user to specify a (per-thread) stack for running
signal handlers, and a SA_ONSTACK flag for sigaction() to ask to use the
alternative stack for a specific handler.

So far these features were stubbed, and this patch provides a complete
implementation, and also a test - which overflows the stack and tries
to recover with a signal handler (without SA_ONSTACK properly working,
the test crashes when it tries to run the signal handler).

Fixes #809.

Proper support of sigaltstack() is important for golang (see issue #522).

Signed-off-by: Nadav Har'El <nyh@scylladb.com>
Message-Id: <20170212084137.18512-1-nyh@scylladb.com>
myechuri pushed a commit to myechuri/osv that referenced this issue Jun 22, 2017
@nyh @myechuri
signals: proper support for sigaltstack() and SA_ONSTACK sigaction flag
bb99273 
When an application gets a SIGSEGV because it overflowed the thread's
stack, it is pointless to try to run a signal handler on the same stack
which has no room to run on. This is why Linux provides a sigaltstack()
function which allows the user to specify a (per-thread) stack for running
signal handlers, and a SA_ONSTACK flag for sigaction() to ask to use the
alternative stack for a specific handler.

So far these features were stubbed, and this patch provides a complete
implementation, and also a test - which overflows the stack and tries
to recover with a signal handler (without SA_ONSTACK properly working,
the test crashes when it tries to run the signal handler).

Fixes cloudius-systems#809.

Proper support of sigaltstack() is important for golang (see issue cloudius-systems#522).

Signed-off-by: Nadav Har'El <nyh@scylladb.com>
Message-Id: <20170212084137.18512-1-nyh@scylladb.com>
@HawxChen HawxChen mentioned this issue Jul 26, 2017
Closed
@wkozaczuk
Copy link
Collaborator

WIth the latest commit d76e530 we seem to have pretty solid support of Golang apps on OSv. Two applications - golang-example and golang-httpserver function well (especially the latter one even under heavy load) when compiled with almost latest Golang 1.10.1. I think we can now close this issue.

@nyh
Copy link
Contributor

nyh commented May 21, 2018

I think you are right! Thank you for all your hard work on this. Nice to finally close this issue after almost 4 years.
And thanks also to @benoit-canet @HawxChen @penberg and whomever else I forgot for your code that went into Go support and for the moral support :-)

@nyh nyh closed this as completed May 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@pdziepak @penberg @nyh @6D65 @dorlaor @wkozaczuk