Rainer Orth writes:
> * On Solaris 8/x86 with native TLS, SETCONTEXT_CLOBBERS_TLS was
> incorrectly defined, causing a proc.c compilation failure:
>
> /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:105:4: error: #error unknown
> case for SETCONTEXT_CLOBBERS_TLS
> /vol/gcc/src/hg/trunk/local/
Ian Lance Taylor writes:
> Ian Lance Taylor writes:
>
>> Right now it looks like there is a bug, or at least an incompatibility,
>> in the 64-bit versions of getcontext and setcontext. It looks like
>> calling setcontext on the 32-bit version does not change the value of
>> TLS variables, which
Ian Lance Taylor writes:
> Right now it looks like there is a bug, or at least an incompatibility,
> in the 64-bit versions of getcontext and setcontext. It looks like
> calling setcontext on the 32-bit version does not change the value of
> TLS variables, which is also the case on GNU/Linux. I
Ian Lance Taylor writes:
> Rainer Orth writes:
>
>> All tests hang with the default -test.timeout=240.
>
> Thanks for providing access to a Solaris system.
>
> Right now it looks like there is a bug, or at least an incompatibility,
> in the 64-bit versions of getcontext and setcontext. It loo
Rainer Orth writes:
> All tests hang with the default -test.timeout=240.
Thanks for providing access to a Solaris system.
Right now it looks like there is a bug, or at least an incompatibility,
in the 64-bit versions of getcontext and setcontext. It looks like
calling setcontext on the 32-bi
On 12/14/2011 05:04 PM, Ian Lance Taylor wrote:
> The OpenBSD thread runtime. It's similar to old LinuxThreads, but
> with only 1 kernel thread per process IIUC.
Oh, hmmm, that might be a problem.
The other Go compiler seems to use the rfork system call to create new
threads, passing RFPROC
Paolo Bonzini writes:
> On 12/14/2011 04:45 PM, Ian Lance Taylor wrote:
>>> > - sigaltstack always returns EINVAL when using threads;
>> That is odd. sigaltstack is very useful when using threads.
>>
>>> > - the threads are identified by the runtime from their stack pointer,
>>> > so you risk
On 12/14/2011 04:45 PM, Ian Lance Taylor wrote:
> - sigaltstack always returns EINVAL when using threads;
That is odd. sigaltstack is very useful when using threads.
> - the threads are identified by the runtime from their stack pointer,
> so you risk confusing the runtime very much if you
Paolo Bonzini writes:
> On 12/14/2011 04:00 PM, Ian Lance Taylor wrote:
>>
>> The other Go compiler already supports OpenBSD, so it must be possible
>> in some sense.
>
> Do they have specialised code for OpenBSD? I said "it cannot work" in
> the sense that:
>
> - *context functions are not ther
On 12/14/2011 04:00 PM, Ian Lance Taylor wrote:
> > This implementation relies on the functions getcontext, setcontext, and
> > makecontext. If there are systems which don't have those, getcontext
> > and setcontext can be replaced by setjmp and longjmp, but there is no
> > obvious replaceme
Peter Maydell writes:
> On 14 December 2011 15:00, Ian Lance Taylor wrote:
>> Anyhow, makecontext is easy to write in a system specific manner. It
>> doesn't even have to be written in assembler, though getcontext and
>> setcontext do have to be assembler. Why not just implement them for
>> AR
On 14 December 2011 15:00, Ian Lance Taylor wrote:
> Anyhow, makecontext is easy to write in a system specific manner. It
> doesn't even have to be written in assembler, though getcontext and
> setcontext do have to be assembler. Why not just implement them for
> ARM?
We're looking at implement
Paolo Bonzini writes:
> On 11/28/2011 06:46 AM, Ian Lance Taylor wrote:
>> This implementation relies on the functions getcontext, setcontext, and
>> makecontext. If there are systems which don't have those, getcontext
>> and setcontext can be replaced by setjmp and longjmp, but there is no
>> o
Uros Bizjak writes:
> Still no success, now I get:
>
> --- FAIL: runtime_test.TestGcSys (4.21 seconds)
> ???:1: used 2554104 extra bytes
> ???:1: using too much memory: 2554104 bytes
> FAIL
> FAIL: runtime
Yeah, I was too aggressive. It had to be fixed in the master library
too.
On 11/28/2011 06:46 AM, Ian Lance Taylor wrote:
This implementation relies on the functions getcontext, setcontext, and
makecontext. If there are systems which don't have those, getcontext
and setcontext can be replaced by setjmp and longjmp, but there is no
obvious replacement for makecontext.
On Wed, Dec 14, 2011 at 12:15 AM, Ian Lance Taylor wrote:
>>> This patch changes the Go library to multiplex goroutines onto operating
>>> system threads. Previously, each new goroutine ran in a separate
>>> thread. That is inefficient for programs with lots of goroutines. This
>>> patch chang
Uros Bizjak writes:
>> This patch changes the Go library to multiplex goroutines onto operating
>> system threads. Previously, each new goroutine ran in a separate
>> thread. That is inefficient for programs with lots of goroutines. This
>> patch changes the library such that it runs a certain
Rainer Orth writes:
> Only a few minor compilation problems, fixed with the following patch.
Thanks. Committed.
Ian
Ian Lance Taylor writes:
> Rainer Orth writes:
>
>> Ian Lance Taylor writes:
>>
>>> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Tested
>>> both with and without -fsplit-stack support. Committed to mainline.
>>
>> Once Go bootstrap works again on Solaris, I notice that there
Rainer Orth writes:
> Ian Lance Taylor writes:
>
>> of any differences between Solaris and GNU/Linux when it comes to the
>> getcontext, setcontext, and makecontext functions?
>
> I've just found something in Solaris 11 makecontext(3C) (NOTES section),
> but that doesn't explain why 32-bit Solar
Ian Lance Taylor writes:
> Rainer Orth writes:
>
>> Ian Lance Taylor writes:
>>
>>> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Tested
>>> both with and without -fsplit-stack support. Committed to mainline.
>>
>> Once Go bootstrap works again on Solaris, I notice that there
Rainer Orth writes:
> Ian Lance Taylor writes:
>
>> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Tested
>> both with and without -fsplit-stack support. Committed to mainline.
>
> Once Go bootstrap works again on Solaris, I notice that there are many
> 64-bit testsuite failure
Ian Lance Taylor writes:
> Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Tested
> both with and without -fsplit-stack support. Committed to mainline.
Once Go bootstrap works again on Solaris, I notice that there are many
64-bit testsuite failures, which have been introduced be
Uros Bizjak writes:
> For some reason I get this failure on alphaev68-pc-linux-gnu:
>
> --- FAIL: runtime_test.TestGcSys (4.64 seconds)
> using 64 MB
> using too much memory: 64 MB
I see the same on Solaris/x86:
--- FAIL: runtime_test.TestGcSys (2.76 seconds)
using 63 MB
Rainer Orth writes:
> Unfortunately, this patch broke Solaris bootstrap (and would break IRIX
> bootstrap if this ever started working again):
>
> /vol/gcc/src/hg/trunk/local/libgo/runtime/go-signal.c:221:1: error:
> conflicting types for 'sigignore'
> In file included from
> /vol/gcc/src/hg/tr
Ian Lance Taylor writes:
> This patch changes the Go library to multiplex goroutines onto operating
> system threads. Previously, each new goroutine ran in a separate
> thread. That is inefficient for programs with lots of goroutines. This
> patch changes the library such that it runs a certai
Hello!
> This patch changes the Go library to multiplex goroutines onto operating
> system threads. Previously, each new goroutine ran in a separate
> thread. That is inefficient for programs with lots of goroutines. This
> patch changes the library such that it runs a certain numbers of
> thre
27 matches
Mail list logo
