[9fans] comment and newline in define
lu...@proxima.alt.za
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
Christopher Nielsen
The [568]c compilers in the Go tree are based on the Inferno/Plan 9 compilers. Did something change?
erik quanstrom
> 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
Rob Pike
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
lu...@proxima.alt.za
> 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
Christopher Nielsen
> 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
Christopher Nielsen
[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.
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.
Ethan Grammatikidis
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?
lu...@proxima.alt.za
> 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
erik quanstrom
> 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
lu...@proxima.alt.za
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
Eric Van Hensbergen
>> 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
Rob Pike
Is the porting process active?
-rob
Devon H. O'Dell
I haven't had time, but have made promises. I'll start tonight.
--dho
> -rob
>
>
Francisco J Ballesteros
Francisco J Ballesteros
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.
Jack Johnson
> 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?
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
Francisco J Ballesteros
those like me that didn't attend usenix?
erik quanstrom
> 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
Eric Van Hensbergen
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
Eric Van Hensbergen
those that wish to take a look.
Hopefully I merged it properly.
-eric
erik quanstrom
> 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
ron minnich
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
Devon H. O'Dell
Or syscall implementation or net / fd / etc implementation.
pkg/runtime should be easy. I'll do it tonight.
--dho
> - erik
>
>
ron minnich
> 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
Steve Simon
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
Charles Forsyth
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.
cinap_...@gmx.de
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
Russ Cox
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
Lucio De Re
>
> i think people get too hung up on trying to make
> the port back perfect. just make it work.
> then make it better.
>
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
Lucio De Re
>
> 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.
>
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