On Fri, Sep 2, 2016 at 1:35 AM, Nadav Har'El wrote:
>
> On Fri, Sep 2, 2016 at 12:58 AM, Paweł Dziepak
> wrote:
>
>> On 1 September 2016 at 12:05, Nadav Har'El wrote:
>>
>> BUT, from the code we've inspected, it seems that golang-compiled code
>>> doesn't use this technique. Instead, it seems i
On Fri, Sep 2, 2016 at 12:58 AM, Paweł Dziepak
wrote:
> On 1 September 2016 at 12:05, Nadav Har'El wrote:
>
> BUT, from the code we've inspected, it seems that golang-compiled code
>> doesn't use this technique. Instead, it seems it uses arch_prctl's
>> ARCH_SET_FS to completely take over the fs
On 1 September 2016 at 23:05, Nadav Har'El wrote:
> Hi, we are trying to run code compiled with the golang compiler to on the
> OSv kernel.
> OSv is a unikernel (kernel for a virtual-machine intending to run a single
> program at a time). It is mostly compatible with the Linux glibc ABI,
> meanin
On 1 September 2016 at 12:05, Nadav Har'El wrote:
> Hi, we are trying to run code compiled with the golang compiler to on the
> OSv kernel.
> OSv is a unikernel (kernel for a virtual-machine intending to run a single
> program at a time). It is mostly compatible with the Linux glibc ABI,
> meanin
Starting the runtime and calling the init functions are handled by a
global initializer in the .so. In glibc argc/v are passed to the
global initializer, and I believe the Go runtime will use them to
initialize os.Args.
Calls to exported functions will block until the runtime is initialized.
On T
Hi thanks a lot for your explanations.
So we are suposed to load the c-shared so then run the init().
Do we must pass argc, argv to the .so initializer and that all ?
Or must we then call GoStart after doing this ?
Best regards
Benoît
On Thu, Sep 1, 2016 at 9:54 PM, David Crawshaw wrote:
On Thu, Sep 1, 2016 at 10:40 PM, David Crawshaw wrote:
> It sounds like you'll need to use external linking if you need
> runtime.tlsg to be TLS IE. Using c-shared is reasonable if you have
> some machinery to do the equivalent of dlopen and call the global
> initializer the runtime inserts into
On Thu, Sep 1, 2016 at 3:50 PM, Nadav Har'El wrote:
>
> On Thu, Sep 1, 2016 at 10:40 PM, David Crawshaw wrote:
>>
>> It sounds like you'll need to use external linking if you need
>> runtime.tlsg to be TLS IE. Using c-shared is reasonable if you have
>> some machinery to do the equivalent of dlop
On Thu, Sep 1, 2016 at 3:29 PM, Nadav Har'El wrote:
>
> On Thu, Sep 1, 2016 at 6:21 PM, David Crawshaw wrote:
>>
>> I've just spent the last two days in the same code porting the runtime
>> to a similarly almost-linux-ELF system, so I may have some information
>> that's useful to you. There are s
On Thu, Sep 1, 2016 at 6:21 PM, David Crawshaw wrote:
> I've just spent the last two days in the same code porting the runtime
> to a similarly almost-linux-ELF system, so I may have some information
> that's useful to you. There are several variants on how Go does this
> depending on the system,
I've just spent the last two days in the same code porting the runtime
to a similarly almost-linux-ELF system, so I may have some information
that's useful to you. There are several variants on how Go does this
depending on the system, so please bear with me if I slip up.
If we fix GOOS=linux, GOA
Hi, we are trying to run code compiled with the golang compiler to on the
OSv kernel.
OSv is a unikernel (kernel for a virtual-machine intending to run a single
program at a time). It is mostly compatible with the Linux glibc ABI,
meaning that you can "mostly" take unmodified Linux executable code
12 matches
Mail list logo
