[9fans] comment and newline in define

[9fans] comment and newline in define

[lucio]

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

Re: [9fans] comment and newline in define

[Christopher Nielsen]

[-- 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 --]

Re: [9fans] comment and newline in define

[erik quanstrom]

> 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

Re: [9fans] comment and newline in define

[Rob Pike]

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

Re: [9fans] comment and newline in define

[Christopher Nielsen]

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

[9fans] Go/Inferno toolchain (Was: comment and newline in define)

[lucio]

> 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

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in define)

[Christopher Nielsen]

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

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[lucio]

> 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

[erik quanstrom]

> 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

[lucio]

>> 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

[Eric Van Hensbergen]

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

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[Rob Pike]

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

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[Devon H. O'Dell]

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
>
>

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[Francisco J Ballesteros]

Which things are yet to be done to get the port done?

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[Francisco J Ballesteros]

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?
>

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[Jack Johnson]

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?

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[Eric Van Hensbergen]

>
> 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

[Francisco J Ballesteros]

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
>
>

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[Eric Van Hensbergen]

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
>>
>>
>
>

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[erik quanstrom]

> 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

[Eric Van Hensbergen]

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
>
>

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[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.

- erik

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[ron minnich]

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

[Steve Simon]

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

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[Charles Forsyth]

>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

[Lucio De Re]

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

[cinap_lenrek]

[-- 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

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[Russ Cox]

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

[Lucio De Re]

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

[Devon H. O'Dell]

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
>
>

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in

[ron minnich]

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

Re: [9fans] Go/Inferno toolchain (Was: comment and newline in define)

[Ethan Grammatikidis]

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
>
>