* [9fans] comment and newline in define @ 2010-06-25 15:35 lucio [not found] ` <AANLkTilhVWAu8htoIL903rtMK1z9Sw88pSfEASawc5Xi@mail.gmail.com> 0 siblings, 1 reply; 32+ messages in thread From: lucio @ 2010-06-25 15:35 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
[parent not found: <AANLkTilhVWAu8htoIL903rtMK1z9Sw88pSfEASawc5Xi@mail.gmail.com>]
* Re: [9fans] comment and newline in define [not found] ` <AANLkTilhVWAu8htoIL903rtMK1z9Sw88pSfEASawc5Xi@mail.gmail.com> @ 2010-06-26 0:50 ` Christopher Nielsen 2010-06-26 0:58 ` erik quanstrom 2010-06-26 5:19 ` [9fans] Go/Inferno toolchain (Was: comment and newline in define) lucio 0 siblings, 2 replies; 32+ messages in thread From: Christopher Nielsen @ 2010-06-26 0:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 877 bytes --] 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, <lucio@proxima.alt.za> 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 [-- Attachment #2: Type: text/html, Size: 1138 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] comment and newline in define 2010-06-26 0:50 ` Christopher Nielsen @ 2010-06-26 0:58 ` erik quanstrom 2010-06-26 4:18 ` Rob Pike 2010-06-26 5:19 ` [9fans] Go/Inferno toolchain (Was: comment and newline in define) lucio 1 sibling, 1 reply; 32+ messages in thread From: erik quanstrom @ 2010-06-26 0:58 UTC (permalink / raw) To: 9fans > 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 <u.h> #include <libc.h> #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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] comment and newline in define 2010-06-26 0:58 ` erik quanstrom @ 2010-06-26 4:18 ` Rob Pike 2010-06-26 6:15 ` Christopher Nielsen 0 siblings, 1 reply; 32+ messages in thread From: Rob Pike @ 2010-06-26 4:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] comment and newline in define 2010-06-26 4:18 ` Rob Pike @ 2010-06-26 6:15 ` Christopher Nielsen 0 siblings, 0 replies; 32+ messages in thread From: Christopher Nielsen @ 2010-06-26 6:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Jun 25, 2010 at 21:18, Rob Pike <robpike@gmail.com> 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* [9fans] Go/Inferno toolchain (Was: comment and newline in define) 2010-06-26 0:50 ` Christopher Nielsen 2010-06-26 0:58 ` erik quanstrom @ 2010-06-26 5:19 ` lucio 2010-06-26 6:46 ` Christopher Nielsen 2010-06-26 7:37 ` [9fans] Go/Inferno toolchain (Was: comment and newline in define) Ethan Grammatikidis 1 sibling, 2 replies; 32+ messages in thread From: lucio @ 2010-06-26 5:19 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in define) 2010-06-26 5:19 ` [9fans] Go/Inferno toolchain (Was: comment and newline in define) lucio @ 2010-06-26 6:46 ` Christopher Nielsen 2010-06-26 9:26 ` [9fans] Go/Inferno toolchain (Was: comment and newline in lucio 2010-06-26 7:37 ` [9fans] Go/Inferno toolchain (Was: comment and newline in define) Ethan Grammatikidis 1 sibling, 1 reply; 32+ messages in thread From: Christopher Nielsen @ 2010-06-26 6:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Jun 25, 2010 at 22:19, <lucio@proxima.alt.za> 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-26 6:46 ` Christopher Nielsen @ 2010-06-26 9:26 ` lucio 2010-06-26 10:34 ` erik quanstrom 2010-06-28 22:03 ` Eric Van Hensbergen 0 siblings, 2 replies; 32+ messages in thread From: lucio @ 2010-06-26 9:26 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-26 9:26 ` [9fans] Go/Inferno toolchain (Was: comment and newline in lucio @ 2010-06-26 10:34 ` erik quanstrom 2010-06-26 11:00 ` lucio 2010-06-28 22:03 ` Eric Van Hensbergen 1 sibling, 1 reply; 32+ messages in thread From: erik quanstrom @ 2010-06-26 10:34 UTC (permalink / raw) To: lucio, 9fans > 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-26 10:34 ` erik quanstrom @ 2010-06-26 11:00 ` lucio 0 siblings, 0 replies; 32+ messages in thread From: lucio @ 2010-06-26 11:00 UTC (permalink / raw) To: 9fans >> 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-26 9:26 ` [9fans] Go/Inferno toolchain (Was: comment and newline in lucio 2010-06-26 10:34 ` erik quanstrom @ 2010-06-28 22:03 ` Eric Van Hensbergen 2010-06-29 17:24 ` Rob Pike 1 sibling, 1 reply; 32+ messages in thread From: Eric Van Hensbergen @ 2010-06-28 22:03 UTC (permalink / raw) To: lucio, Fans of the OS Plan 9 from Bell Labs On Sat, Jun 26, 2010 at 4:26 AM, <lucio@proxima.alt.za> 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. 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'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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-28 22:03 ` Eric Van Hensbergen @ 2010-06-29 17:24 ` Rob Pike 2010-06-29 17:31 ` Devon H. O'Dell ` (2 more replies) 0 siblings, 3 replies; 32+ messages in thread From: Rob Pike @ 2010-06-29 17:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Jun 28, 2010 at 3:03 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote: > On Sat, Jun 26, 2010 at 4:26 AM, <lucio@proxima.alt.za> 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. 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'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 Is the porting process active? -rob ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 17:24 ` Rob Pike @ 2010-06-29 17:31 ` Devon H. O'Dell 2010-06-29 17:36 ` Francisco J Ballesteros 2010-06-29 18:10 ` Eric Van Hensbergen 2 siblings, 0 replies; 32+ messages in thread From: Devon H. O'Dell @ 2010-06-29 17:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2010/6/29 Rob Pike <robpike@gmail.com>: > On Mon, Jun 28, 2010 at 3:03 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote: >> On Sat, Jun 26, 2010 at 4:26 AM, <lucio@proxima.alt.za> 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. 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'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 > > Is the porting process active? I haven't had time, but have made promises. I'll start tonight. --dho > -rob > > ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 17:24 ` Rob Pike 2010-06-29 17:31 ` Devon H. O'Dell @ 2010-06-29 17:36 ` Francisco J Ballesteros 2010-06-29 17:48 ` Francisco J Ballesteros 2010-06-29 18:10 ` Eric Van Hensbergen 2 siblings, 1 reply; 32+ messages in thread From: Francisco J Ballesteros @ 2010-06-29 17:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Which things are yet to be done to get the port done? ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 17:36 ` Francisco J Ballesteros @ 2010-06-29 17:48 ` Francisco J Ballesteros 2010-06-29 18:02 ` Jack Johnson 0 siblings, 1 reply; 32+ messages in thread From: Francisco J Ballesteros @ 2010-06-29 17:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 <nemo@lsub.org> wrote: > Which things are yet to be done to get the port done? > ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 17:48 ` Francisco J Ballesteros @ 2010-06-29 18:02 ` Jack Johnson 0 siblings, 0 replies; 32+ messages in thread From: Jack Johnson @ 2010-06-29 18:02 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Jun 29, 2010 at 9:48 AM, Francisco J Ballesteros <nemo@lsub.org> 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? ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 17:24 ` Rob Pike 2010-06-29 17:31 ` Devon H. O'Dell 2010-06-29 17:36 ` Francisco J Ballesteros @ 2010-06-29 18:10 ` Eric Van Hensbergen 2010-06-29 18:12 ` Francisco J Ballesteros 2010-06-29 18:32 ` erik quanstrom 2 siblings, 2 replies; 32+ messages in thread From: Eric Van Hensbergen @ 2010-06-29 18:10 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > > 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 18:10 ` Eric Van Hensbergen @ 2010-06-29 18:12 ` Francisco J Ballesteros 2010-06-29 20:30 ` Eric Van Hensbergen 2010-06-29 18:32 ` erik quanstrom 1 sibling, 1 reply; 32+ messages in thread From: Francisco J Ballesteros @ 2010-06-29 18:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 <ericvh@gmail.com> wrote: >> >> 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 > > ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 18:12 ` Francisco J Ballesteros @ 2010-06-29 20:30 ` Eric Van Hensbergen 0 siblings, 0 replies; 32+ messages in thread From: Eric Van Hensbergen @ 2010-06-29 20:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 <nemo@lsub.org> wrote: > 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 <ericvh@gmail.com> wrote: >>> >>> 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 >> >> > > ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 18:10 ` Eric Van Hensbergen 2010-06-29 18:12 ` Francisco J Ballesteros @ 2010-06-29 18:32 ` erik quanstrom 2010-06-29 20:45 ` Eric Van Hensbergen 1 sibling, 1 reply; 32+ messages in thread From: erik quanstrom @ 2010-06-29 18:32 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 18:32 ` erik quanstrom @ 2010-06-29 20:45 ` Eric Van Hensbergen 2010-06-29 20:52 ` erik quanstrom 0 siblings, 1 reply; 32+ messages in thread From: Eric Van Hensbergen @ 2010-06-29 20:45 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 <quanstro@labs.coraid.com> 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. i got everything compiled > rather quickly, but something came up before i could get > going on the runtime. > > - erik > > ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 20:45 ` Eric Van Hensbergen @ 2010-06-29 20:52 ` erik quanstrom 2010-06-29 21:03 ` ron minnich 2010-06-29 21:15 ` Devon H. O'Dell 0 siblings, 2 replies; 32+ messages in thread From: erik quanstrom @ 2010-06-29 20:52 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 20:52 ` erik quanstrom @ 2010-06-29 21:03 ` ron minnich 2010-06-29 21:36 ` Steve Simon ` (3 more replies) 2010-06-29 21:15 ` Devon H. O'Dell 1 sibling, 4 replies; 32+ messages in thread From: ron minnich @ 2010-06-29 21:03 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 21:03 ` ron minnich @ 2010-06-29 21:36 ` Steve Simon 2010-06-29 21:54 ` Charles Forsyth ` (2 subsequent siblings) 3 siblings, 0 replies; 32+ messages in thread From: Steve Simon @ 2010-06-29 21:36 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 21:03 ` ron minnich 2010-06-29 21:36 ` Steve Simon @ 2010-06-29 21:54 ` Charles Forsyth 2010-06-30 9:25 ` Lucio De Re 2010-06-29 22:35 ` cinap_lenrek 2010-06-29 23:00 ` Russ Cox 3 siblings, 1 reply; 32+ messages in thread From: Charles Forsyth @ 2010-06-29 21:54 UTC (permalink / raw) To: 9fans >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. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 21:54 ` Charles Forsyth @ 2010-06-30 9:25 ` Lucio De Re 0 siblings, 0 replies; 32+ messages in thread From: Lucio De Re @ 2010-06-30 9:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 21:03 ` ron minnich 2010-06-29 21:36 ` Steve Simon 2010-06-29 21:54 ` Charles Forsyth @ 2010-06-29 22:35 ` cinap_lenrek 2010-06-29 23:00 ` Russ Cox 3 siblings, 0 replies; 32+ messages in thread From: cinap_lenrek @ 2010-06-29 22:35 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 2077 bytes --] 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 [-- Attachment #2: Type: message/rfc822, Size: 3896 bytes --] From: ron minnich <rminnich@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Go/Inferno toolchain (Was: comment and newline in Date: Tue, 29 Jun 2010 14:03:36 -0700 Message-ID: <AANLkTin7bcjTrQ-Kugu7-vJ8Byq68HKrSKAsLEM9zAAj@mail.gmail.com> 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 21:03 ` ron minnich ` (2 preceding siblings ...) 2010-06-29 22:35 ` cinap_lenrek @ 2010-06-29 23:00 ` Russ Cox 2010-06-30 8:17 ` Lucio De Re 3 siblings, 1 reply; 32+ messages in thread From: Russ Cox @ 2010-06-29 23:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 23:00 ` Russ Cox @ 2010-06-30 8:17 ` Lucio De Re 0 siblings, 0 replies; 32+ messages in thread From: Lucio De Re @ 2010-06-30 8:17 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 20:52 ` erik quanstrom 2010-06-29 21:03 ` ron minnich @ 2010-06-29 21:15 ` Devon H. O'Dell 2010-06-29 21:27 ` ron minnich 1 sibling, 1 reply; 32+ messages in thread From: Devon H. O'Dell @ 2010-06-29 21:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2010/6/29 erik quanstrom <quanstro@quanstro.net>: > 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 > > ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in 2010-06-29 21:15 ` Devon H. O'Dell @ 2010-06-29 21:27 ` ron minnich 0 siblings, 0 replies; 32+ messages in thread From: ron minnich @ 2010-06-29 21:27 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, Jun 29, 2010 at 2:15 PM, Devon H. O'Dell <devon.odell@gmail.com> 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 ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [9fans] Go/Inferno toolchain (Was: comment and newline in define) 2010-06-26 5:19 ` [9fans] Go/Inferno toolchain (Was: comment and newline in define) lucio 2010-06-26 6:46 ` Christopher Nielsen @ 2010-06-26 7:37 ` Ethan Grammatikidis 1 sibling, 0 replies; 32+ messages in thread From: Ethan Grammatikidis @ 2010-06-26 7:37 UTC (permalink / raw) To: lucio, Fans of the OS Plan 9 from Bell Labs 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 > > ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2010-06-30 9:25 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-06-25 15:35 [9fans] comment and newline in define lucio [not found] ` <AANLkTilhVWAu8htoIL903rtMK1z9Sw88pSfEASawc5Xi@mail.gmail.com> 2010-06-26 0:50 ` Christopher Nielsen 2010-06-26 0:58 ` erik quanstrom 2010-06-26 4:18 ` Rob Pike 2010-06-26 6:15 ` Christopher Nielsen 2010-06-26 5:19 ` [9fans] Go/Inferno toolchain (Was: comment and newline in define) lucio 2010-06-26 6:46 ` Christopher Nielsen 2010-06-26 9:26 ` [9fans] Go/Inferno toolchain (Was: comment and newline in lucio 2010-06-26 10:34 ` erik quanstrom 2010-06-26 11:00 ` lucio 2010-06-28 22:03 ` Eric Van Hensbergen 2010-06-29 17:24 ` Rob Pike 2010-06-29 17:31 ` Devon H. O'Dell 2010-06-29 17:36 ` Francisco J Ballesteros 2010-06-29 17:48 ` Francisco J Ballesteros 2010-06-29 18:02 ` Jack Johnson 2010-06-29 18:10 ` Eric Van Hensbergen 2010-06-29 18:12 ` Francisco J Ballesteros 2010-06-29 20:30 ` Eric Van Hensbergen 2010-06-29 18:32 ` erik quanstrom 2010-06-29 20:45 ` Eric Van Hensbergen 2010-06-29 20:52 ` erik quanstrom 2010-06-29 21:03 ` ron minnich 2010-06-29 21:36 ` Steve Simon 2010-06-29 21:54 ` Charles Forsyth 2010-06-30 9:25 ` Lucio De Re 2010-06-29 22:35 ` cinap_lenrek 2010-06-29 23:00 ` Russ Cox 2010-06-30 8:17 ` Lucio De Re 2010-06-29 21:15 ` Devon H. O'Dell 2010-06-29 21:27 ` ron minnich 2010-06-26 7:37 ` [9fans] Go/Inferno toolchain (Was: comment and newline in define) Ethan Grammatikidis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).