Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
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
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
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
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
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
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
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 WPUBG3 1819c080 f 000c data -0 0 000d data -0 0 PC 0x00020439 pread+0x7 /sys/src/libc/9syscall/pread.s:5 SP 0xdeffcd70 ECODE 0xf010080c EFLAG 0x0286 CS 0x0023 DS0x001b SS 0x001b GS 0x005b FS0x ES 0x001b TRAP0x0040 system call AX 0x0032 BX 0x00032b4c CX 0x0001 DX 0x DI 0x080e7468 SI 0x 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 --- Begin Message --- 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--- End Message ---
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
>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.
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
On Tue Jun 29 22:04:19 BST 2010, rminn...@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
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
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
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
2010/6/29 erik quanstrom : > On Tue Jun 29 16:46:40 EDT 2010, eri...@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 > >
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
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
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
On Tue Jun 29 16:46:40 EDT 2010, eri...@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
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
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. i got everything compiled > rather quickly, but something came up before i could get > going on the runtime. > > - erik > >
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
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 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 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 >> >> > >
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
> 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
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
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 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 > >
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
> > 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
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
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?
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
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? >
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
Which things are yet to be done to get the port done?
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
2010/6/29 Rob Pike : > On Mon, Jun 28, 2010 at 3:03 PM, Eric Van Hensbergen wrote: >> 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. 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 > >
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
On Mon, Jun 28, 2010 at 3:03 PM, Eric Van Hensbergen wrote: > 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. 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
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
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. 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
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
>> 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
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
> 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
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in
> 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
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in define)
On 26 Jun 2010, at 06:19, lu...@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
Re: [9fans] Go/Inferno toolchain (Was: comment and newline in define)
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