在 2016年8月30日星期二 UTC+8下午8:22:19,Nadav Har'El写道:
> On Tue, Aug 30, 2016 at 6:08 AM, wrote:
> Hello everyone,
>
> I am new to OSv,these days I have done some experiments on OSv,I found
> it was a great project,I am interested in it very much.But now I have some
>
On Wed, Aug 31, 2016 at 6:13 PM, Timmons C. Player
wrote:
> This commit fixes two observed issues with the vmxnet3 driver:
>
> * Handle both missing SOP and EOP descriptors in the rx loop. ESXi
> drops descriptors under load.
> * Always leave at least one Tx
On Wed, Aug 31, 2016 at 4:04 PM, Benoit Canet <
benoit.canet.cont...@gmail.com> wrote:
> Needed by libraries produced by the Go compiler.
>
> With this patch and the golang app the runtime
> init crash later because of a vdso issue.
>
> It can be examinated by insertion an abort()
> before osv
This commit fixes two observed issues with the vmxnet3 driver:
* Handle both missing SOP and EOP descriptors in the rx loop. ESXi
drops descriptors under load.
* Always leave at least one Tx descriptor available. The driver
appears to hang when it runs out of them.
Signed-off-by: Timmons C.
On Wed, Aug 31, 2016 at 5:33 PM, Nadav Har'El wrote:
> I'm more worried about the symbol(sym) part of this code... What if there
> is no symbol involved? In this case (again see readelf --relocs for your
> object), there is no object...
>
> I think the code involved is the
On Wed, Aug 31, 2016 at 5:13 PM, Benoît Canet
wrote:
>case R_X86_64_TPOFF64:
>// FIXME: assumes TLS segment comes before DYNAMIC segment
>
I'm not sure this code even runs when loading a shared object. I think it
only runs when loading the kernel, and
In an earlier review in
https://groups.google.com/forum/#!msg/osv-dev/PW3bkaVCuMg/340vWUeimdMJ
and also today in another thread, I pointed out the problems with this
arch_prctl thing which makes this patch either incomplete or even
counter-productive:
1. After a thread does ARCH_SET_FS, if it get
case R_X86_64_TPOFF64:
// FIXME: assumes TLS segment comes before DYNAMIC segment
This is not the case:
See in the dump:
000c8d90 :
c8d90: 48 8b 0d 29 72 38 00mov0x387229(%rip),%rcx#
44ffc0 <_DYNAMIC+0x200>
c8d97: 64 48 8b 09 mov
This is what I saw in the code managing the flags.
By anyway I think you are right and shared is an "impasse".
On Wed, Aug 31, 2016 at 4:06 PM, Nadav Har'El wrote:
>
> On Wed, Aug 31, 2016 at 4:26 PM, Benoît Canet > wrote:
>
>>
>> Buildmode
On Wed, Aug 31, 2016 at 4:26 PM, Benoît Canet
wrote:
>
> Buildmode shared alone crash.
>
>
>
the flags are |= between them.
>
This is not what I see in https://golang.org/src/cmd/go/build.go
But it seems these two options indeed have a funny interaction between
On Wed, Aug 31, 2016 at 4:26 PM, Benoît Canet
wrote:
>
>
> Go use it's own tls see: http://blog.altoros.com/golang-internals-part-5-
> runtime-bootstrap-process.html
>
Thanks. Interesting.
It is very sad, and surprising, that Go does this: If I understand
Buildmode shared alone crash.
the flags are |= between them.
Go use it's own tls see:
http://blog.altoros.com/golang-internals-part-5-runtime-bootstrap-process.html
On Wed, Aug 31, 2016 at 3:22 PM, Nadav Har'El wrote:
>
> On Wed, Aug 31, 2016 at 4:05 PM, Benoit Canet
The c-shared is intented to build C libraries hence it
does not export main and it's initialization does not
set the fs register with arch_prctl() leading to a crash.
Use -buildmode=shared -buildmode=pie to produce a library
which export main and is position independant while having
and init
Needed by libraries produced by the Go compiler.
With this patch and the golang app the runtime
init crash later because of a vdso issue.
It can be examinated by insertion an abort()
before osv send SIGSEGV to the program.
(gdb) bt
at /usr/lib/golang/src/runtime/mheap.go:503
argc=,
14 matches
Mail list logo