https://codereview.appspot.com/6569068/diff/18001/src/cmd/dist/buildruntime.c
File src/cmd/dist/buildruntime.c (right):
https://codereview.appspot.com/6569068/diff/18001/src/cmd/dist/buildruntime.c#newcode111
src/cmd/dist/buildruntime.c:111: "#define tos_pid 48\n"
On 2013/01/10 03:19:22, ality wrote:
gobuf_pc orOn 2013/01/08 06:03:09, akumar wrote:
On 2012/10/06 22:22:38, rsc wrote:
Should this be #define tos_pid(r) 48(r) to be like the others?
The semantics I had in mind were analogous to constants likeShould this be #define tos_pid(r) 48(r) to be like the others?
g_stackguard: tos_pid is just an offset of "pid" from top of struct
Still, I can change it if you like.
I would just do #define procid(r) 48(r) to match the amd64 definition.It's clear that we get it from the tos in this case.
Done.
Also updated runtime·rfork code in sys_plan9_386.s to match.
https://codereview.appspot.com/6569068/diff/43003/src/pkg/runtime/os_plan9.h
File src/pkg/runtime/os_plan9.h (right):
https://codereview.appspot.com/6569068/diff/43003/src/pkg/runtime/os_plan9.h#newcode86
src/pkg/runtime/os_plan9.h:86: #define NERRMAX 128 /* max length of note
string */
On 2013/01/10 03:19:22, ality wrote:
Why not just ERRMAX?
Done.Why not just ERRMAX?
https://codereview.appspot.com/6569068/diff/43003/src/pkg/runtime/stack.h
File src/pkg/runtime/stack.h (right):
https://codereview.appspot.com/6569068/diff/43003/src/pkg/runtime/stack.h#newcode64
src/pkg/runtime/stack.h:64: // Maximum size of NFrame (386 vs amd64) +
call frame.
On 2013/01/10 03:19:22, ality wrote:
NFrame is not present (at least by name) in the 386 kernels and
it's size actually contains the call frame. Also, the 32-bit
kernels leave 256 bytes between the old stack pointer and the
note handler frame as an aid for debugging. Shouldn't we take
that into account?
So on amd64 we need at least 368 bytes whereas on 386 we need
at least 476. I don't know about the arm systems.
Maybe the comment should read something like:
// We need enough space for the note handler frame setup
// by the kernel. This varies among the architectures we
// support. 512 bytes ought to be enough for anybody.
Done.NFrame is not present (at least by name) in the 386 kernels and
it's size actually contains the call frame. Also, the 32-bit
kernels leave 256 bytes between the old stack pointer and the
note handler frame as an aid for debugging. Shouldn't we take
that into account?
So on amd64 we need at least 368 bytes whereas on 386 we need
at least 476. I don't know about the arm systems.
Maybe the comment should read something like:
// We need enough space for the note handler frame setup
// by the kernel. This varies among the architectures we
// support. 512 bytes ought to be enough for anybody.
https://codereview.appspot.com/6569068/diff/43003/src/pkg/runtime/thread_plan9.c
File src/pkg/runtime/thread_plan9.c (right):
https://codereview.appspot.com/6569068/diff/43003/src/pkg/runtime/thread_plan9.c#newcode18
src/pkg/runtime/thread_plan9.c:18: m->gsignal = runtime·malg(32*1024);
On 2013/01/10 03:19:22, ality wrote:
Why 32Kb?
Should be enough for panic routines.Why 32Kb?
https://codereview.appspot.com/6569068/diff/43003/src/pkg/runtime/thread_plan9.c#newcode223
src/pkg/runtime/thread_plan9.c:223: int8 *exitstatus;
On 2013/01/10 03:19:22, ality wrote:
Too much typing. Just make this "status".
Done.Too much typing. Just make this "status".
https://codereview.appspot.com/6569068/diff/43003/src/pkg/runtime/thread_plan9.c#newcode295
src/pkg/runtime/thread_plan9.c:295: runtime·panicstring("call of nil
func value");
On 2013/01/10 03:19:22, ality wrote:
One too many tabs.
Done.One too many tabs.
https://codereview.appspot.com/6569068/