From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Wed, 12 Jan 2011 17:36:51 -0500
To: ality@pbrane.org, 9fans@9fans.net
Message-ID: <314ea9d7e23ffbdf3d31c0a3dc3461ab@brasstown.quanstro.net>
In-Reply-To: <20110112223102.GA5183@dinah>
References: <AANLkTin8_MZ0B8GSDDSa-k87aOi2-88zpN4n2suHv5gd@mail.gmail.com>
	<AANLkTi=6nmqYK8VHphhO2im-_QNwB836KguQP3oZaaMN@mail.gmail.com>
	<20110111185536.GA6160@dinah>
	<AANLkTimj+nRcVxTViHT7snZrzQx2hTf+7YmH+mEySVfd@mail.gmail.com>
	<20110112223102.GA5183@dinah>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] plan9 go output faults on 9vx but ok on cpu
Topicbox-Message-UUID: 9525dfcc-ead6-11e9-9d60-3106f5b1d025

> I'm talking about Go's linker. In the Go runtime, the G and M
> pointers need to be in a per-process storage area. On Plan 9,
> this is the stack. Right now, the offset of the pointers is
> hard-coded in the linker to be just before the Tos structure.
> The problem is that the value that was chosen is not correct
> when running on 9vx because the top of the stack is is at
> 0x10000000 instead of 0xdffff000 (as it is on native Plan 9).
>
> I think that the Go 8l should not hard-code this value but,
> instead, discover it somehow ... though I'm not sure how.

main9.s sets _tos on entry.  why not just use _tos as
the c glue code does?

- erik