Svante Signell, le Wed 21 May 2014 09:47:08 +0200, a écrit :
+# Special treatment of EWOULDBLOCK for GNU/Hurd
+# /usr/include/bits/errno.h: #define EWOULDBLOCK EAGAIN
+if egrep 'define EWOULDBLOCK EAGAIN' gen-sysinfo.go /dev/null 21;
then
+ egrep '^const EWOULDBLOCK =
On Wed, 2014-05-07 at 10:18 +0200, Svante Signell wrote:
On Tue, 2014-05-06 at 15:26 +0200, Samuel Thibault wrote:
Attached is an updated patch8.diff. Arch specific code to
src/libgo/mksysinfo.sh has been added, now other systems are not
affected by the patch except the SYS_FCNTL part.
For that
On Fri, 2014-05-16 at 06:20 -0700, Ian Lance Taylor wrote:
On Fri, May 16, 2014 at 1:03 AM, Svante Signell
svante.sign...@gmail.com wrote:
For that part of the patch without it the build on GNU/Hurd fails. On
the other hand SYS_FCNTL is not defined for e.g. GNU/Linux either. This
is used
On Tue, 2014-05-06 at 15:26 +0200, Samuel Thibault wrote:
Svante Signell, le Tue 06 May 2014 15:25:38 +0200, a écrit :
On Tue, 2014-05-06 at 15:07 +0200, Samuel Thibault wrote:
Svante Signell, le Tue 06 May 2014 15:05:20 +0200, a écrit :
On Tue, 2014-05-06 at 14:51 +0200, Samuel Thibault
On Fri, 2014-05-02 at 12:52 +0200, Samuel Thibault wrote:
Svante Signell, le Fri 02 May 2014 12:45:56 +0200, a écrit :
On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote:
Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
So we just need to fix guardsize in our
Just to explicitly ask for it:
Svante Signell, le Tue 06 May 2014 10:06:49 +0200, a écrit :
For some (yet) unknown reason all libgo tests fails with a segfault when
run in the build tree: make, sh or something else, the test commands are
rather hard to track.
Doesn't that dump a core? Do you
On Tue, 2014-05-06 at 14:51 +0200, Samuel Thibault wrote:
Just to explicitly ask for it:
Svante Signell, le Tue 06 May 2014 10:06:49 +0200, a écrit :
For some (yet) unknown reason all libgo tests fails with a segfault when
run in the build tree: make, sh or something else, the test
Svante Signell, le Tue 06 May 2014 15:05:20 +0200, a écrit :
On Tue, 2014-05-06 at 14:51 +0200, Samuel Thibault wrote:
Just to explicitly ask for it:
Svante Signell, le Tue 06 May 2014 10:06:49 +0200, a écrit :
For some (yet) unknown reason all libgo tests fails with a segfault when
On Tue, 2014-05-06 at 15:07 +0200, Samuel Thibault wrote:
Svante Signell, le Tue 06 May 2014 15:05:20 +0200, a écrit :
On Tue, 2014-05-06 at 14:51 +0200, Samuel Thibault wrote:
Just to explicitly ask for it:
Svante Signell, le Tue 06 May 2014 10:06:49 +0200, a écrit :
For some
On Fri, 2014-05-02 at 00:45 +0200, Samuel Thibault wrote:
Hello,
Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit :
- Without split stack enabled around 70 libgo tests pass and 50 fails,
most of them with a segfault.
- Enabling split stack and using the libc Samuel built all
Svante Signell, le Fri 02 May 2014 10:18:12 +0200, a écrit :
Thread 4 (Thread 1205.4):
#0 0x019977b7 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:132
err = optimized out
err = optimized out
user_option = 3
user_timeout = 48
m = 0x532370
Svante Signell, le Fri 02 May 2014 10:03:23 +0200, a écrit :
On Fri, 2014-05-02 at 00:45 +0200, Samuel Thibault wrote:
Hello,
Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit :
- Without split stack enabled around 70 libgo tests pass and 50 fails,
most of them with a
Svante Signell, le Fri 02 May 2014 10:18:12 +0200, a écrit :
task130(pid1182)-vm_allocate (33562796 8364 0) = 0x3 ((os/kern) no space
available)
task130(pid1182)-vm_allocate (33571160 8364 0) = 0 33570816
While inspecting this, I realized this is from __pthread_stack_alloc,
the only caller
Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
So we just need to fix guardsize in our libpthread.
It was not so difficult actually.
Svante, could you try this libpthread:
http://people.debian.org/~sthibault/tmp/libpthread.so.0.3
Thanks,
Samuel
On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote:
Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
So we just need to fix guardsize in our libpthread.
(And I'll have a look at it).
Maybe this can fix the around 40 segfaults (of 50 failures) when split
stack is disabled
Svante Signell, le Fri 02 May 2014 12:45:56 +0200, a écrit :
On Fri, 2014-05-02 at 12:00 +0200, Samuel Thibault wrote:
Samuel Thibault, le Fri 02 May 2014 11:57:53 +0200, a écrit :
So we just need to fix guardsize in our libpthread.
(And I'll have a look at it).
Maybe this can fix
Hello,
Svante Signell, le Thu 24 Apr 2014 10:39:10 +0200, a écrit :
- Without split stack enabled around 70 libgo tests pass and 50 fails,
most of them with a segfault.
- Enabling split stack and using the libc Samuel built all 122 libgo
tests fail with a segfault.
Please provide segfault
Quoting Svante Signell (2014-04-24 10:39:10)
On Fri, 2014-04-18 at 10:03 +0200, Samuel Thibault wrote:
Samuel Thibault, le Thu 17 Apr 2014 00:03:45 +0200, a écrit :
Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
Well, the first step is to verify that
±On Sat, 2014-04-26 at 08:53 +0200, Justus Winter wrote:
Quoting Svante Signell (2014-04-24 10:39:10)
On Fri, 2014-04-18 at 10:03 +0200, Samuel Thibault wrote:
Samuel Thibault, le Thu 17 Apr 2014 00:03:45 +0200, a écrit :
Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
Quoting Svante Signell (2014-04-26 13:59:57)
For reference, here are my notes about one of these crashes (Svante,
is this still current?):
Yes it is, thanks for your help so far. Is the rpctrace bug you
mentioned that the wrong ports are reported?
~~~ snip ~~~
[...]
On Fri, 2014-04-18 at 10:03 +0200, Samuel Thibault wrote:
Samuel Thibault, le Thu 17 Apr 2014 00:03:45 +0200, a écrit :
Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
and similar configury is correct
Samuel Thibault, le Thu 17 Apr 2014 00:03:45 +0200, a écrit :
Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
and similar configury is correct for the Hurd,
I have added the corresponding field, so we can
Samuel Thibault, le Sat 12 Apr 2014 01:04:49 +0200, a écrit :
Samuel Thibault, le Fri 11 Apr 2014 23:51:44 +0200, a écrit :
So, do we really want to let munmap poke a hole at address 0 and thus
let further vm_map() return address 0?
i.e. we could apply this:
I have applied it.
Samuel
Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
and similar configury is correct for the Hurd,
I have added the corresponding field, so we can just use the same offset
as on Linux.
Samuel
On Fri, Apr 11, 2014 at 11:51:44PM +0200, Samuel Thibault wrote:
It's indeed:
/* This function is called at program startup time to make sure that
mmap, munmap, and getpagesize are resolved if linking dynamically.
We want to resolve them while we have enough stack for them, rather
Thomas Schwinge, le Wed 09 Apr 2014 09:36:42 +0200, a écrit :
Well, the first step is to verify that TARGET_THREAD_SPLIT_STACK_OFFSET
and similar configury is correct for the Hurd,
It's not. I've checked what TARGET_THREAD_SPLIT_STACK_OFFSET is, it's
an offset inside the tcbhead_t structure,
On Fri, 2014-04-04 at 21:14 +0200, Samuel Thibault wrote:
Hello,
Thomas Schwinge, le Wed 26 Jun 2013 23:30:03 +0200, a écrit :
On Sat, 22 Jun 2013 08:15:46 -0700, Ian Lance Taylor i...@google.com
wrote:
Go can work without split stack. In that case libgo will use much
larger stacks
Hi!
On Wed, 9 Apr 2014 09:05:46 +0200, Svante Signell svante.sign...@gmail.com
wrote:
On Fri, 2014-04-04 at 21:14 +0200, Samuel Thibault wrote:
Thomas Schwinge, le Wed 26 Jun 2013 23:30:03 +0200, a écrit :
On Sat, 22 Jun 2013 08:15:46 -0700, Ian Lance Taylor i...@google.com
wrote:
Hello,
Thomas Schwinge, le Wed 26 Jun 2013 23:30:03 +0200, a écrit :
On Sat, 22 Jun 2013 08:15:46 -0700, Ian Lance Taylor i...@google.com wrote:
Go can work without split stack. In that case libgo will use much
larger stacks for goroutines, to reduce the chance of running out of
stack
Hi!
On Sat, 22 Jun 2013 08:15:46 -0700, Ian Lance Taylor i...@google.com wrote:
Go can work without split stack. In that case libgo will use much
larger stacks for goroutines, to reduce the chance of running out of
stack space (see StackMin in libgo/runtime/proc.c). So the number of
Hi!
On Sat, 22 Jun 2013 01:15:08 +0200, Richard Braun rbr...@sceen.net wrote:
On Sat, Jun 22, 2013 at 12:52:03AM +0200, Thomas Schwinge wrote:
But anyway, what is the split-stack run-time/startup code doing so that
it makes vm_allocate behave erratically? Isn't vm_allocate a real system
Hi!
On Fri, 21 Jun 2013 16:16:55 -0700 (PDT), Roland McGrath rol...@hack.frob.com
wrote:
Split-stack is fundamentally incompatible with __hurd_threadvar_location et
Not fundamentally: if split-stack were properly integrated into glibc,
our threadvar resolver could track back split-stack's
On Sat, Jun 22, 2013 at 12:19 AM, Thomas Schwinge
tho...@codesourcery.com wrote:
On Fri, 21 Jun 2013 16:16:55 -0700 (PDT), Roland McGrath
rol...@hack.frob.com wrote:
Split-stack is fundamentally incompatible with __hurd_threadvar_location et
Not fundamentally: if split-stack were properly
Hi!
This is tracked down from the GCC Go testsuite, where every execution
test would fail à la:
mmap errno 1073741846
fatal error: mmap
That is EINVAL (but that actually is a straw man, as it should turn out),
and mmap has been invoked from [GCC]/libbacktrace/mmap.c:backtrace_alloc
(but
On Sat, Jun 22, 2013 at 12:52:03AM +0200, Thomas Schwinge wrote:
But anyway, what is the split-stack run-time/startup code doing so that
it makes vm_allocate behave erratically? Isn't vm_allocate a real system
call after all, but relies on some threadvar state? It's now too late to
figure it
35 matches
Mail list logo
