From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Fri, 25 Jun 2010 17:35:43 +0200 From: lucio@proxima.alt.za MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [9fans] comment and newline in define Topicbox-Message-UUID: 36f3f0ce-ead6-11e9-9d60-3106f5b1d025 In /sys/src/cmd/cc/macbody:298,301 if(c == '\n') { yyerror("comment and newline in define: %s", s->name); break; } suggests that all "C" compilers explictly forbid newlines within comments when a macro is #defined. At a glance, I'd say that removing the above will eliminate what to me seems an anachronism. Am I overlooking something? The Go toolchain code unsurprisingly uses multiline comments in src/cmd/ld/elf.h and I'm loath to request the Go Authors to hack their header file for a non-standard feature of the Plan 9 compilers. I concede that the header in question would benefit, aesthetically, from having those comments adjusted. ++L From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 25 Jun 2010 17:50:55 -0700 Message-ID: From: Christopher Nielsen To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0016367d5e60b437810489e4472a Subject: Re: [9fans] comment and newline in define Topicbox-Message-UUID: 36fcb394-ead6-11e9-9d60-3106f5b1d025 --0016367d5e60b437810489e4472a Content-Type: text/plain; charset=UTF-8 The [568]c compilers in the Go tree are based on the Inferno/Plan 9 compilers. Did something change? On Jun 25, 2010 8:47 AM, wrote: In /sys/src/cmd/cc/macbody:298,301 if(c == '\n') { yyerror("comment and newline in define: %s", s->name); break; } suggests that all "C" compilers explictly forbid newlines within comments when a macro is #defined. At a glance, I'd say that removing the above will eliminate what to me seems an anachronism. Am I overlooking something? The Go toolchain code unsurprisingly uses multiline comments in src/cmd/ld/elf.h and I'm loath to request the Go Authors to hack their header file for a non-standard feature of the Plan 9 compilers. I concede that the header in question would benefit, aesthetically, from having those comments adjusted. ++L --0016367d5e60b437810489e4472a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The [568]c compilers in the Go tree are based on the Inferno/Plan 9 comp= ilers. Did something change?

On Jun 25, 2010 8:47 AM, <lucio@proxima.alt.za> wrote:

In /sys/= src/cmd/cc/macbody:298,301

=C2=A0 =C2=A0 =C2=A0 =C2=A0if(c =3D=3D '\n') {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yyerror("comme= nt and newline in define: %s", s->name);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0break;
=C2=A0 =C2=A0 =C2=A0 =C2=A0}

suggests that all "C" compilers explictly forbid newlines within<= br> comments when a macro is #defined. =C2=A0At a glance, I'd say that remo= ving
the above will eliminate what to me seems an anachronism. =C2=A0Am I
overlooking something?

The Go toolchain code unsurprisingly uses multiline comments in
src/cmd/ld/elf.h and I'm loath to request the Go Authors to hack their<= br> header file for a non-standard feature of the Plan 9 compilers. =C2=A0I
concede that the header in question would benefit, aesthetically, from
having those comments adjusted.

++L


--0016367d5e60b437810489e4472a-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Fri, 25 Jun 2010 20:58:48 -0400 To: 9fans@9fans.net Message-ID: <503a7bb59e4d2b42457812d0f6e071ca@kw.quanstro.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] comment and newline in define Topicbox-Message-UUID: 37049f28-ead6-11e9-9d60-3106f5b1d025 > The [568]c compilers in the Go tree are based on the Inferno/Plan 9 > compilers. Did something change? yes. they've changed a number of things. here's a sample of what the op ment #include #include #define x /* this is * such a drag */ y void main(void) { int y; x = 1; print("%d\n", x); exits(""); } allowing that would seem to me to invite trouble. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <503a7bb59e4d2b42457812d0f6e071ca@kw.quanstro.net> References: <503a7bb59e4d2b42457812d0f6e071ca@kw.quanstro.net> From: Rob Pike Date: Fri, 25 Jun 2010 21:18:11 -0700 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] comment and newline in define Topicbox-Message-UUID: 3711b37a-ead6-11e9-9d60-3106f5b1d025 What's changed is that, to simplify porting (to systems other than Plan 9), the compilers in the Go distribution are built by gcc, not the Plan 9 C compilers. It's easy to fix that header file. Patches willingly accepted. -rob From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Sat, 26 Jun 2010 07:19:59 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [9fans] Go/Inferno toolchain (Was: comment and newline in define) Topicbox-Message-UUID: 371710fe-ead6-11e9-9d60-3106f5b1d025 > The [568]c compilers in the Go tree are based on the Inferno/Plan 9 > compilers. Did something change? Yes, they added ELF, didn't they? And they used GCC to compile everything, which is the bit I've been trying to consolidate since more or less the very beginning. The objective of the consolidation is three-fold: (1) upgrade the Plan 9 toolchain to whatever fresh and progressive features the Go toolchain provides, including targetting ELF (and 6c, not to discounted); (2) port Go to Plan 9 and (3) add to plan9port the ability the Go toolchain (as an alternative to GCC) for program development. There's a fourth objective, but it may be above my skill level, which is to port all the other Plan 9 and/or Inferno architectures into the consolidated toolchain. Also, one needs to consolidate the linker and libmach in some fashion and, lastly, somehow blend in binutils, GCC and GDB into the project. Although the decision by the GCC developers to allow C++ code into the GCC codebase, as reported in slashdot, puts a bit of a spanner in the works. It seems a little bit more than the average summer of code endeavour, but I'm not discouraging anyone who may want to tackle any of the above. It would be nice if I was made aware of others who may be interested. Right now, I'm catching up with work I did late December last year, before it gets lost, buried or uselessly out of date. ++L From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <503a7bb59e4d2b42457812d0f6e071ca@kw.quanstro.net> Date: Fri, 25 Jun 2010 23:15:50 -0700 Message-ID: From: Christopher Nielsen To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] comment and newline in define Topicbox-Message-UUID: 37203d14-ead6-11e9-9d60-3106f5b1d025 On Fri, Jun 25, 2010 at 21:18, Rob Pike wrote: > What's changed is that, to simplify porting (to systems other than > Plan 9), the compilers in the Go distribution are built by gcc, not > the Plan 9 C compilers. Oops. I should have noticed that. :-) Sorry for the noise. -- Christopher Nielsen "They who can give up essential liberty for temporary safety, deserve neither liberty nor safety." --Benjamin Franklin "The tree of liberty must be refreshed from time to time with the blood of patriots & tyrants." --Thomas Jefferson From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 25 Jun 2010 23:46:45 -0700 Message-ID: From: Christopher Nielsen To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in define) Topicbox-Message-UUID: 37266400-ead6-11e9-9d60-3106f5b1d025 On Fri, Jun 25, 2010 at 22:19, wrote: [snip] > There's a fourth objective, but it may be above my skill level, which > is to port all the other Plan 9 and/or Inferno architectures into the > consolidated toolchain. [snip] I've been (slowly) working on this for MIPS with the long-term plan of writing a MIPS target for Go. I haven't had a lot of time to work on it, which is why it is going slowly. I've written some tools to automate the initial changes to the Plan 9 toolchain. I am sure they have bugs (they've only been tested on MIPS so far), but I can dig them up, clean them up, and share them, if someone wants to work on the toolchains for other targets. -- Christopher Nielsen "They who can give up essential liberty for temporary safety, deserve neither liberty nor safety." --Benjamin Franklin "The tree of liberty must be refreshed from time to time with the blood of patriots & tyrants." --Thomas Jefferson From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: From: Ethan Grammatikidis To: lucio@proxima.alt.za, Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 26 Jun 2010 08:37:21 +0100 References: Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in define) Topicbox-Message-UUID: 372c2ea8-ead6-11e9-9d60-3106f5b1d025 On 26 Jun 2010, at 06:19, lucio@proxima.alt.za wrote: >> The [568]c compilers in the Go tree are based on the Inferno/Plan 9 >> compilers. Did something change? > > Yes, they added ELF, didn't they? And they used GCC to compile > everything, which is the bit I've been trying to consolidate since > more or less the very beginning. The objective of the consolidation > is three-fold: (1) upgrade the Plan 9 toolchain to whatever fresh and > progressive features the Go toolchain provides, including targetting > ELF (and 6c, not to discounted); (2) port Go to Plan 9 and (3) add to > plan9port the ability the Go toolchain (as an alternative to GCC) for > program development. > > There's a fourth objective, but it may be above my skill level, which > is to port all the other Plan 9 and/or Inferno architectures into the > consolidated toolchain. Also, one needs to consolidate the linker and > libmach in some fashion and, lastly, somehow blend in binutils, GCC > and GDB into the project. Although the decision by the GCC developers > to allow C++ code into the GCC codebase, as reported in slashdot, puts > a bit of a spanner in the works. There's a lot of great goals above, but I really don't get this last bit. You want gcc and binutils on and/or targeting Plan 9? And if you do, why is the C++ code anything more than a minor bootstrapping issue? > > It seems a little bit more than the average summer of code endeavour, > but I'm not discouraging anyone who may want to tackle any of the > above. It would be nice if I was made aware of others who may be > interested. Right now, I'm catching up with work I did late December > last year, before it gets lost, buried or uselessly out of date. > > ++L > > From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> To: 9fans@9fans.net Date: Sat, 26 Jun 2010 11:26:21 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 3731dd1c-ead6-11e9-9d60-3106f5b1d025 > but I can dig > them up, clean them up, and share them, My particular concern is to encourage convergence towards a single source distribution rather than divergence as seems to have been the case so far with Plan 9 native, Inferno, p9p and now Go. What I have chosen to do, ill-advised as it may be, is to set up a mercurial repository to re-distribute hacked Go sources that mostly contain harmless changes that make it possible to compile the Go sources and specifically the development toolchain with the Plan 9 toolchain. I'm presently trying to bring the work I did last year into this repository and at the same time keep track of the Go release. I'm hoping that others will also find this repository useful or, even better, make reasonable suggestions on how to improve it to achieve objectives of benefit to the Plan 9 community. Mercurial is great this way because one can stream changesets back into the release repository when they are ready, but allows different groups to work on possibly conflicting projects and worry about merging much later. Anyway, if anyone wants to access the repository, I will gladly grant him or her access. At the same time, my recommendation is that as much as possible, changes should be submitted through codereview (see the Go documentation for details, Russ has done a very good job of explaining things there) rather than as alternative development streams. But some changes are worth having before they mature, a public repository is a good place to dump such changes and let others try them out or comment on them. As I think about it, it seems strange that I should be duplicating codereview, but I think Plan 9's more aggressive approach to filtering changes was influential in my thinking, my subconscious assumption is that most changes need multiple iterations _before_ submitting, but this assumes that reviewers are an expensive commodity as is the case at Bell Labs. I don't know if the Go Author are operating under the same conditions. And, obvious sequitur, what would it take to replace Plan 9's "patch" approach with a "codereview" one? It seems to me that everyone might benefit from it. ++L From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sat, 26 Jun 2010 06:34:49 -0400 To: lucio@proxima.alt.za, 9fans@9fans.net Message-ID: <6b38de346a9fc846a24cf6114d2ad4c7@kw.quanstro.net> In-Reply-To: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 3737d42e-ead6-11e9-9d60-3106f5b1d025 > My particular concern is to encourage convergence towards a single > source distribution rather than divergence as seems to have been the > case so far with Plan 9 native, Inferno, p9p and now Go. What I have [...] > And, obvious sequitur, what would it take to replace Plan 9's "patch" > approach with a "codereview" one? It seems to me that everyone might > benefit from it. i suppose it needs saying: bell labs, not to be confused with google, ... - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Sat, 26 Jun 2010 13:00:45 +0200 From: lucio@proxima.alt.za In-Reply-To: <6b38de346a9fc846a24cf6114d2ad4c7@kw.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 37401a12-ead6-11e9-9d60-3106f5b1d025 >> My particular concern is to encourage convergence towards a single >> source distribution rather than divergence as seems to have been the >> case so far with Plan 9 native, Inferno, p9p and now Go. What I have > [...] >> And, obvious sequitur, what would it take to replace Plan 9's "patch" >> approach with a "codereview" one? It seems to me that everyone might >> benefit from it. > > i suppose it needs saying: bell labs, not to be confused with google, ... Hard to confuse the two, but it doesn't hurt to clarify. Codereview is run as an independent operation and would give Bell Labs some breathing space. Good or bad, that's much more difficult to decide, but I think that those who might participate in the review process (and remember that the Go Authors seem to be behind codereview for Go and we know some of them well) would have Plan 9's best interest at heart too. ++L From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> Date: Mon, 28 Jun 2010 17:03:06 -0500 Message-ID: From: Eric Van Hensbergen To: lucio@proxima.alt.za, Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 37fcf63c-ead6-11e9-9d60-3106f5b1d025 On Sat, Jun 26, 2010 at 4:26 AM, wrote: >> but I can dig >> them up, clean them up, and share them, > > My particular concern is to encourage convergence towards a single > source distribution rather than divergence as seems to have been the > case so far with Plan 9 native, Inferno, p9p and now Go. What I have > chosen to do, ill-advised as it may be, is to set up a mercurial > repository to re-distribute hacked Go sources that mostly contain > harmless changes that make it possible to compile the Go sources and > specifically the development toolchain with the Plan 9 toolchain. =A0I'm > presently trying to bring the work I did last year into this > repository and at the same time keep track of the Go release. > I've had a composite repo of previous attempts (well, Sape's previous attempt) at doing this (for some time) at: http://code.google.com/p/go-plan9/ I'm happy to add anyone to the committer/admin list, although my preference is to keep the main branch in sync with go and have folks attempts at conversion in sub-branches. You are of course welcome to maintain your own repo with your own effort, I just figured if everyone had a common place to see what approaches people were using we might get there faster.... -eric From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> From: Rob Pike Date: Tue, 29 Jun 2010 10:24:08 -0700 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 38e8cc38-ead6-11e9-9d60-3106f5b1d025 On Mon, Jun 28, 2010 at 3:03 PM, Eric Van Hensbergen wro= te: > On Sat, Jun 26, 2010 at 4:26 AM, =A0 wrote: >>> but I can dig >>> them up, clean them up, and share them, >> >> My particular concern is to encourage convergence towards a single >> source distribution rather than divergence as seems to have been the >> case so far with Plan 9 native, Inferno, p9p and now Go. What I have >> chosen to do, ill-advised as it may be, is to set up a mercurial >> repository to re-distribute hacked Go sources that mostly contain >> harmless changes that make it possible to compile the Go sources and >> specifically the development toolchain with the Plan 9 toolchain. =A0I'm >> presently trying to bring the work I did last year into this >> repository and at the same time keep track of the Go release. >> > > I've had a composite repo of previous attempts (well, Sape's previous > attempt) at doing this (for some time) at: > http://code.google.com/p/go-plan9/ > > I'm happy to add anyone to the committer/admin list, although my > preference is to keep the main branch in sync with go and have folks > attempts at conversion in sub-branches. =A0You are of course welcome to > maintain your own repo with your own effort, I just figured if > everyone had a common place to see what approaches people were using > we might get there faster.... > > =A0 =A0 =A0 -eric Is the porting process active? -rob From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> Date: Tue, 29 Jun 2010 13:31:15 -0400 Message-ID: From: "Devon H. O'Dell" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 3907b814-ead6-11e9-9d60-3106f5b1d025 2010/6/29 Rob Pike : > On Mon, Jun 28, 2010 at 3:03 PM, Eric Van Hensbergen w= rote: >> On Sat, Jun 26, 2010 at 4:26 AM, =A0 wrote: >>>> but I can dig >>>> them up, clean them up, and share them, >>> >>> My particular concern is to encourage convergence towards a single >>> source distribution rather than divergence as seems to have been the >>> case so far with Plan 9 native, Inferno, p9p and now Go. What I have >>> chosen to do, ill-advised as it may be, is to set up a mercurial >>> repository to re-distribute hacked Go sources that mostly contain >>> harmless changes that make it possible to compile the Go sources and >>> specifically the development toolchain with the Plan 9 toolchain. =A0I'= m >>> presently trying to bring the work I did last year into this >>> repository and at the same time keep track of the Go release. >>> >> >> I've had a composite repo of previous attempts (well, Sape's previous >> attempt) at doing this (for some time) at: >> http://code.google.com/p/go-plan9/ >> >> I'm happy to add anyone to the committer/admin list, although my >> preference is to keep the main branch in sync with go and have folks >> attempts at conversion in sub-branches. =A0You are of course welcome to >> maintain your own repo with your own effort, I just figured if >> everyone had a common place to see what approaches people were using >> we might get there faster.... >> >> =A0 =A0 =A0 -eric > > Is the porting process active? I haven't had time, but have made promises. I'll start tonight. --dho > -rob > > From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> Date: Tue, 29 Jun 2010 19:36:55 +0200 Message-ID: From: Francisco J Ballesteros To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 38f9419e-ead6-11e9-9d60-3106f5b1d025 Which things are yet to be done to get the port done? From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> Date: Tue, 29 Jun 2010 19:48:09 +0200 Message-ID: From: Francisco J Ballesteros To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 390fff1a-ead6-11e9-9d60-3106f5b1d025 FTS, I'm interesting in getting Go here because I'm going to write the i.e. window system (successor of o/live, o/mero, ...) also in go, to run at least the viewer native on unix systems. The C version is still cooking. On Tue, Jun 29, 2010 at 7:36 PM, Francisco J Ballesteros wrote: > Which things are yet to be done to get the port done? > From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> Date: Tue, 29 Jun 2010 10:02:15 -0800 Message-ID: From: Jack Johnson To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 39353e42-ead6-11e9-9d60-3106f5b1d025 On Tue, Jun 29, 2010 at 9:48 AM, Francisco J Ballesteros wrote: > FTS, I'm interesting in getting Go here because I'm going to write > the i.e. window system (successor of o/live, o/mero, ...) also in go, to run > at least the viewer native on unix systems. The C version is still cooking. Is there an overview/paper/etc. for i.e? From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> Date: Tue, 29 Jun 2010 13:10:04 -0500 Message-ID: From: Eric Van Hensbergen To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 393e32c2-ead6-11e9-9d60-3106f5b1d025 > > Is the porting process active? > It seems to be an opportunistic concurrent activity (which is why I tried to create a central repo so we'd get some benefit from the sparse multiple activities). Most people were just waiting for Andrey :) There is some stuff that Forysth/Jmk have been looking at to allow for the segment registers, but Russ had suggested workaround at USENIX that I don't think anyone has had time to try yet. So here's what my take on what needs to be done: a) Simple logistics (makefile/script transformations, Sape's branch has some of this, what the right way to do this in order to be integrated back into the mainline go tree is an open question) b) support or workaround for the segment register stuff c) runtime support People seem to be mostly getting hung up on (a), (b) is probably the trickiest bit, and I think (c) is just a matter of sitting down and getting it done. I wonder if one way of avoiding (a) is just to rig to cross-compile from Linux/MacOSX to Plan 9 and get (b) and (c) done first then work back to (a), just because it seems like it would be more satisfying. -eric From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> Date: Tue, 29 Jun 2010 20:12:37 +0200 Message-ID: From: Francisco J Ballesteros To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 3956b91e-ead6-11e9-9d60-3106f5b1d025 Anyone (Russ?) can repeat here aprox. what the workaround for b was, for those like me that didn't attend usenix? On Tue, Jun 29, 2010 at 8:10 PM, Eric Van Hensbergen wro= te: >> >> Is the porting process active? >> > > It seems to be an opportunistic concurrent activity (which is why I > tried to create a central repo so we'd get some benefit from the > sparse multiple activities). =C2=A0Most people were just waiting for Andr= ey > :) > > There is some stuff that Forysth/Jmk have been looking at to allow for > the segment registers, but Russ had suggested workaround at USENIX > that I don't think anyone has had time to try yet. > > So here's what my take on what needs to be done: > > a) Simple logistics (makefile/script transformations, Sape's branch > has some of this, what the right way to do this in order to be > integrated back into the mainline go tree is an open question) > b) support or workaround for the segment register stuff > c) runtime support > > People seem to be mostly getting hung up on (a), (b) is probably the > trickiest bit, and I think (c) is just a matter of sitting down and > getting it done. > > I wonder if one way of avoiding (a) is just to rig to cross-compile > from Linux/MacOSX to Plan 9 and get (b) and (c) done first then work > back to (a), just because it seems like it would be more satisfying. > > =C2=A0 =C2=A0-eric > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 29 Jun 2010 14:32:01 -0400 To: 9fans@9fans.net Message-ID: <19b728d48aa74d67b8402c1b9727c80e@coraid.com> In-Reply-To: References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 397bcf2e-ead6-11e9-9d60-3106f5b1d025 > a) Simple logistics (makefile/script transformations, Sape's branch > has some of this, what the right way to do this in order to be > integrated back into the mainline go tree is an open question) [...] > > I wonder if one way of avoiding (a) is just to rig to cross-compile > from Linux/MacOSX to Plan 9 and get (b) and (c) done first then work > back to (a), just because it seems like it would be more satisfying. i found that (a) wasn't hard. i got everything compiled rather quickly, but something came up before i could get going on the runtime. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> Date: Tue, 29 Jun 2010 15:30:30 -0500 Message-ID: From: Eric Van Hensbergen To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 3a69e5a6-ead6-11e9-9d60-3106f5b1d025 I was sleep-deprived much of the week, so my memory is most likely not exact (so hopefully Russ will provide a clarification), but I believe he said something along the lines of pointing to the top of the stack as a workaround. I haven't had a chance to look at it yet, so that's about as much of a hint as I can give at the moment. -eric On Tue, Jun 29, 2010 at 1:12 PM, Francisco J Ballesteros wr= ote: > Anyone (Russ?) can repeat here aprox. what the workaround for b was, for > those like me that didn't attend usenix? > > On Tue, Jun 29, 2010 at 8:10 PM, Eric Van Hensbergen w= rote: >>> >>> Is the porting process active? >>> >> >> It seems to be an opportunistic concurrent activity (which is why I >> tried to create a central repo so we'd get some benefit from the >> sparse multiple activities). =A0Most people were just waiting for Andrey >> :) >> >> There is some stuff that Forysth/Jmk have been looking at to allow for >> the segment registers, but Russ had suggested workaround at USENIX >> that I don't think anyone has had time to try yet. >> >> So here's what my take on what needs to be done: >> >> a) Simple logistics (makefile/script transformations, Sape's branch >> has some of this, what the right way to do this in order to be >> integrated back into the mainline go tree is an open question) >> b) support or workaround for the segment register stuff >> c) runtime support >> >> People seem to be mostly getting hung up on (a), (b) is probably the >> trickiest bit, and I think (c) is just a matter of sitting down and >> getting it done. >> >> I wonder if one way of avoiding (a) is just to rig to cross-compile >> from Linux/MacOSX to Plan 9 and get (b) and (c) done first then work >> back to (a), just because it seems like it would be more satisfying. >> >> =A0 =A0-eric >> >> > > From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <19b728d48aa74d67b8402c1b9727c80e@coraid.com> References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> <19b728d48aa74d67b8402c1b9727c80e@coraid.com> Date: Tue, 29 Jun 2010 15:45:44 -0500 Message-ID: From: Eric Van Hensbergen To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 3a648430-ead6-11e9-9d60-3106f5b1d025 erik's attempt is now in the go-plan9 repo under its own branch for those that wish to take a look. Hopefully I merged it properly. -eric On Tue, Jun 29, 2010 at 1:32 PM, erik quanstrom wrote: >> a) Simple logistics (makefile/script transformations, Sape's branch >> has some of this, what the right way to do this in order to be >> integrated back into the mainline go tree is an open question) > [...] >> >> I wonder if one way of avoiding (a) is just to rig to cross-compile >> from Linux/MacOSX to Plan 9 and get (b) and (c) done first then work >> back to (a), just because it seems like it would be more satisfying. > > i found that (a) wasn't hard. =A0i got everything compiled > rather quickly, but something came up before i could get > going on the runtime. > > - erik > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 29 Jun 2010 16:52:52 -0400 To: 9fans@9fans.net Message-ID: <0ab4e0867c119e024b86176ede4cd12e@ladd.quanstro.net> In-Reply-To: References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> <19b728d48aa74d67b8402c1b9727c80e@coraid.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 3a7a2f56-ead6-11e9-9d60-3106f5b1d025 On Tue Jun 29 16:46:40 EDT 2010, ericvh@gmail.com wrote: > erik's attempt is now in the go-plan9 repo under its own branch for > those that wish to take a look. > Hopefully I merged it properly. it compiles and links, but obviously doesn't run since there really is no runtime. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <0ab4e0867c119e024b86176ede4cd12e@ladd.quanstro.net> References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> <19b728d48aa74d67b8402c1b9727c80e@coraid.com> <0ab4e0867c119e024b86176ede4cd12e@ladd.quanstro.net> Date: Tue, 29 Jun 2010 14:03:36 -0700 Message-ID: From: ron minnich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 3a7f7574-ead6-11e9-9d60-3106f5b1d025 Can someone remind me of the problem? Is it simply the need to be able to set %gs? Could a write to /dev/arch of something like gs 0xwhatever which sets %gs for that process solve the problem? Or is it bigger than that? ron From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <0ab4e0867c119e024b86176ede4cd12e@ladd.quanstro.net> References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> <19b728d48aa74d67b8402c1b9727c80e@coraid.com> <0ab4e0867c119e024b86176ede4cd12e@ladd.quanstro.net> Date: Tue, 29 Jun 2010 17:15:21 -0400 Message-ID: From: "Devon H. O'Dell" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 3a83c16a-ead6-11e9-9d60-3106f5b1d025 2010/6/29 erik quanstrom : > On Tue Jun 29 16:46:40 EDT 2010, ericvh@gmail.com wrote: >> erik's attempt is now in the go-plan9 repo under its own branch for >> those that wish to take a look. >> Hopefully I merged it properly. > > it compiles and links, but obviously doesn't run > since there really is no runtime. Or syscall implementation or net / fd / etc implementation. pkg/runtime should be easy. I'll do it tonight. --dho > - erik > > From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> <19b728d48aa74d67b8402c1b9727c80e@coraid.com> <0ab4e0867c119e024b86176ede4cd12e@ladd.quanstro.net> Date: Tue, 29 Jun 2010 14:27:44 -0700 Message-ID: From: ron minnich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 3a8f6ec0-ead6-11e9-9d60-3106f5b1d025 On Tue, Jun 29, 2010 at 2:15 PM, Devon H. O'Dell wrote: > Or syscall implementation or net / fd / etc implementation. > pkg/runtime should be easy. I'll do it tonight. It would be nice to avoid a system call if possible :-) ron From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <235ff261d3966d10cc5c5950299e965d@quintile.net> From: "Steve Simon" Date: Tue, 29 Jun 2010 22:36:47 +0100 To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 3a93ee8c-ead6-11e9-9d60-3106f5b1d025 On Tue Jun 29 22:04:19 BST 2010, rminnich@gmail.com wrote: > Can someone remind me of the problem? Is it simply the need to be able > to set %gs? > > Could a write to /dev/arch of something like > gs 0xwhatever > which sets %gs for that process solve the problem? > > Or is it bigger than that? > > ron Ok, my turn with the bad memory. Isn't this exactly what cinap's patch did to allow recent debian releases to run under linuxemu? -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: Charles Forsyth Date: Tue, 29 Jun 2010 22:54:25 +0100 To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 3a9850e4-ead6-11e9-9d60-3106f5b1d025 >Or is it bigger than that? the go toolchain is replete with go-specific things, and produces incompatible .8 files (and perhaps for other architectures), because of the way certain changes were made. as russ suggested, it's probably easiest just to have a /bin/go and put go/8c, go/8l etc in that, as they exist. that would obviously work. he also suggested changing plan9's go/8l to rewrite references to offsets off GS as references to (say) offsets into the privstack data. you'd need to consider whether that would cover all cases correctly, although at the time i thought it would. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <0510bb6f1fcb7c2a30557bc374eba6fa@gmx.de> To: 9fans@9fans.net Date: Wed, 30 Jun 2010 00:35:43 +0200 From: cinap_lenrek@gmx.de In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-rdroxyytytxarupdccofurroby" Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 3aa8a16a-ead6-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-rdroxyytytxarupdccofurroby Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit the segment registers are just indices to the kernels descriptor tables. setting the segment registers can be done with assembly instructions from userspace. but what you need is being able to modify the descriptors in a save way from userspace! i needed this for linuxemu to implement set_thread_area syscalls under plan9 so i made the modifications to the kernel: /n/sources/contrib/cinap_lenrek/segdescpatch it adds the files ldt and gdt to devarch. heres a linuxemu process where glibc has setup a special descriptor and loaded %gs to point to it under plan9: cat /dev/gdt 000b data WPUBG 3 1819c080 fffff 000c data - 0 00000000 00000 000d data - 0 00000000 00000 PC 0x00020439 pread+0x7 /sys/src/libc/9syscall/pread.s:5 SP 0xdeffcd70 ECODE 0xf010080c EFLAG 0x00000286 CS 0x00000023 DS 0x0000001b SS 0x0000001b GS 0x0000005b FS 0x00000000 ES 0x0000001b TRAP 0x00000040 system call AX 0x00000032 BX 0x00032b4c CX 0x00000001 DX 0x00000000 DI 0x080e7468 SI 0x00000000 BP 0xdeffcf2c format of is simple text: /* * format: * idx[4] type[8] flags[8] dpl[1] base[8] limit[5]\n */ idx is the descriptor index (the one you load into a segment registers by the selector) type is code or data dpl is the priority level (usualy just 3 for userspace) base and limit describe the location of the segment (limit is in pages if G flag is set) /* * flags: * P = present * A = accessed (for code/data) * E = expand down (for data) * W = writable (for data) * R = readable (for code) * C = conforming (for code) * G = limit granularity in pages (for code/data) * D = 32 bit operand size (for code) * B = 32 bit stack pointer (for data) * Y = busy (for tss and tss16) * U = available for use by system software */ gdt and ldt are both per process. the only difference between gdt and ldt is that gdt has a small fixed number of descriptors in the gdt that you can modify. the ldt refers to the local descriptor table wich can have up to 2^13 user descriptors. -- cinap --upas-rdroxyytytxarupdccofurroby Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-bounces+cinap_lenrek=gmx.de@9fans.net> X-Flags: 0000 Delivered-To: GMX delivery to cinap_lenrek@gmx.de Received: (qmail invoked by alias); 29 Jun 2010 21:06:08 -0000 Received: from gouda.swtch.com (EHLO gouda.swtch.com) [67.207.142.3] by mx0.gmx.net (mx015) with SMTP; 29 Jun 2010 23:06:08 +0200 Received: from localhost ([127.0.0.1] helo=gouda.swtch.com) by gouda.swtch.com with esmtp (Exim 4.69) (envelope-from <9fans-bounces@9fans.net>) id 1OThy4-0001dS-Dg; Tue, 29 Jun 2010 21:03:44 +0000 Received: from mail-wy0-f177.google.com ([74.125.82.177]) by gouda.swtch.com with esmtp (Exim 4.69) (envelope-from ) id 1OThy2-0001dN-KF for 9fans@9fans.net; Tue, 29 Jun 2010 21:03:42 +0000 Received: by wyb32 with SMTP id 32so48746wyb.36 for <9fans@9fans.net>; Tue, 29 Jun 2010 14:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=DwSvxpDtsy816pV6RaREzlpkIvBHZvj2R2SvbHpovMk=; b=HocTDpfhQIDYGVcdbATwN0wC7Qs9WtwufRdsDHoB8iMnAJsA93r2NBUfFGNlLSw9HA obvlGhz5oV6kK3gcoZ/Jce5gPLcInbf4Awwm/vV0QN8YjW5Xt4HPRSkb4E1cm7ruyJoC rJ7I9MWt6eC1jtj6Hlhv0qMJGsCycRhD2sXe8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=B9sYdLV9yr+gHCnx1tOOD5+S/Mfwd7fVXDlEpdzBVH3PMwOZdkzo8XBklxMp1rAuaq Kg8A41qanzjiPb7a7HP3WTvTBnK4lMA9d0c89qlUFq2Dmo5iqT004YItHTDdyuayVUCU 1WPVZpYRh41adF0RUEIsCF5qEtHYF53IjF1yQ= MIME-Version: 1.0 Received: by 10.216.86.140 with SMTP id w12mr5784287wee.95.1277845416401; Tue, 29 Jun 2010 14:03:36 -0700 (PDT) Received: by 10.216.180.78 with HTTP; Tue, 29 Jun 2010 14:03:36 -0700 (PDT) In-Reply-To: <0ab4e0867c119e024b86176ede4cd12e@ladd.quanstro.net> References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> <19b728d48aa74d67b8402c1b9727c80e@coraid.com> <0ab4e0867c119e024b86176ede4cd12e@ladd.quanstro.net> Date: Tue, 29 Jun 2010 14:03:36 -0700 Message-ID: From: ron minnich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.10 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces@9fans.net Errors-To: 9fans-bounces+cinap_lenrek=gmx.de@9fans.net X-GMX-Antivirus: 0 (no virus found) X-GMX-Antispam: 0 (Sender is in whitelist: rminnich@gmail.com); Detail=5D7Q89H36p4L00VTXC6D4q0N+AH0PUCnetdm6+jp8LF+tAiRn7+lma6RwlXCy1ukem4Xx mt89Mv9SdHr7XJZmXAvwanJf/hYV1; X-GMX-UID: eFIZeCJfX1Vpbssqz2FyuSl3SDc4NAzr Can someone remind me of the problem? Is it simply the need to be able to set %gs? Could a write to /dev/arch of something like gs 0xwhatever which sets %gs for that process solve the problem? Or is it bigger than that? ron --upas-rdroxyytytxarupdccofurroby-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> <19b728d48aa74d67b8402c1b9727c80e@coraid.com> <0ab4e0867c119e024b86176ede4cd12e@ladd.quanstro.net> Date: Tue, 29 Jun 2010 16:00:09 -0700 Message-ID: Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Topicbox-Message-UUID: 3ab7e08a-ead6-11e9-9d60-3106f5b1d025 what i said to people at usenix was approximately the following. i think that porting go to plan 9 - the time to get something working that runs all the go programs - is not more than a week of concerted effort. i also think that it just hasn't been high enough priority for anyone (myself included) to put that amount of effort in. the go runtime sets up the segment registers, with the operating system's help, so that gs points at per-kernel-thread storage. the linker generates references through gs for the pseudo-addressing mode 0(gs), 4(gs), etc. on plan 9 there is already per-kernel-thread storage: it is called the stack. the workaround would be for the linker to know the top of stack address and rewrite 0(gs) and 4(gs) to fixed memory addresses just below the top of the stack. it would be just as efficient as the 0(gs), 4(gs) stuff and not require any kernel changes. the build uses make, yes, and in some places there are even include files that include other include files (gasp!), but writing equivalent mkfiles should take not very much time. we're not doing anything magical, and the particular style in the makefiles should be familiar. there's obviously a lot of divergence between the plan 9 tool chain and the go tool chain. the object files have different format, and so on. to get off the ground i would suggest treating the go copies of the tools as separate programs and libraries from the originals. for example, you might install the go libmach as /386/lib/go/libmach.a and the compiler tool chain as /386/bin/go/8a, /386/bin/go/8c, /386/bin/go/8g, /386/bin/go/8l. the .8 files created by those tools would not be compatible with the standard ones, and the standard nm wouldn't understand the final 8.out, but the final 8.out would run. you'd have to disable the runtime copy of the symbol table (the "nacl" target in 8l already does). anyway, keep everything separate and get it working. once you have a working system then you could worry about reconciling the two worlds to whatever extent is appropriate. i think people get too hung up on trying to make the port back perfect. just make it work. then make it better. russ From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 30 Jun 2010 10:17:26 +0200 From: Lucio De Re To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20100630081726.GA19323@mutter.proxima.alt.za> References: <464534aea8c7fffa248a1368c41acb55@proxima.alt.za> <19b728d48aa74d67b8402c1b9727c80e@coraid.com> <0ab4e0867c119e024b86176ede4cd12e@ladd.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 3acad6cc-ead6-11e9-9d60-3106f5b1d025 On Tue, Jun 29, 2010 at 04:00:09PM -0700, Russ Cox wrote: > > i think people get too hung up on trying to make > the port back perfect. just make it work. > then make it better. > But it's the toolchain I'm after. I like Go a lot, but I feel that a viable toolchain that produces ELF files for Linux is also a worthy objective. And getting the toolchain to produce Plan 9 executable code has already been done, albeit unchecked and about to be lost or forgotten on a server a long way from here. Still, I'd be thrilled to be able to cut my teeth on Go on Plan 9 rather than UBUNTU, so don't let me discourage anyone. I just want 9fans to know that I'm willing to do the slog work to keep the toolchains in sync and they shouldn't go out of their way to make my life unnecessarily difficult :-) ++L From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 30 Jun 2010 11:25:47 +0200 From: Lucio De Re To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20100630092547.GC19323@mutter.proxima.alt.za> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Topicbox-Message-UUID: 3ae17490-ead6-11e9-9d60-3106f5b1d025 On Tue, Jun 29, 2010 at 10:54:25PM +0100, Charles Forsyth wrote: > > the go toolchain is replete with go-specific things, > and produces incompatible .8 files (and perhaps for other architectures), > because of the way certain changes were made. > I've had the Go toolchain successfully compile working "C" source on Plan 9 (for the 386, I seem to recall that the ARM code failed in more spectacular ways that I could not fix immediately) since late last year, but it's fading faster and faster besides getting out of sync with the release code. Problem is, I'm looking to alleviate all compiler warnings, which is easy but terribly invasive and getting that approved for release of the Go source code is not going to be trivial. And it would be exciting if the GCC developers could treat a missing argument name in a function declaration as an unused variable rather than an error. And if anyone wants mkfiles, I have a whole lot of them lurking around. Once again, some changes are invasive and I'm a tad stuck with the target selection. Also, plan9port is an interesting place to play with the Go code, I've done some of that, someone ought to put some effort in that direction. Just so the picture gets a little clearer... ++L