[9fans] Building Go/386

[lu...@proxima.alt.za]

This looks ugly!

cmd/8g
8c 1568: suicide: sys: trap: fault read addr=0x0 pc=0x0003718d
go tool dist: FAILED: /bin/8c -FTVw -I/n/shackle/go/include/plan9 -I/n/shackle/go/include/plan9/386 -I/n/shackle/go/src/cmd/ld -I /n/shackle/go/src/cmd/8g -o $WORK/ggen.8 /n/shackle/go/src/cmd/8g/ggen.c: '/n/shackle/go/pkg/tool/plan9_386/8g' does not exist
warning: /n/shackle/go/src/cmd/8g/gobj.c:38 result of operation not used
shackle% acid 1568
/proc/1568/text:386 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/386
acid: lstk()
abort()+0x0 /sys/src/libc/9sys/abort.c:6
regalloc(o=0x0,tn=0x13bcf8,n=0xdfff5a78)+0xbb /sys/src/cmd/8c/txt.c:314
biggen(a=0x3911c,code=0x3ce5c,l=0x13bcf8,r=0xdfff5c48,t=0x0,true=0x0)+0xd88 /sys/src/cmd/8c/cgen64.c:1522
args=0x1732e
to=0x0
ro=0x0
lo=0x0
cp=0x3ce61
c=0x3ce5c
g=0x1
i=0x0
j=0x13b908
ot=0x0
tmps=0x0
tl=0x0
tr=0x0
op=0x82
lt=0x4ad00
pr=0x0
cgen64(nn=0x13bcf8,n=0x136158)+0x18b2 /sys/src/cmd/8c/cgen64.c:1784
cmp=0x0
sh=0x0
d=0x0
optab=0x3a214
args=0x3911c
dr=0x1
l=0x13bcf8
r=0xdfff5c48
li=0x0
ri=0x3
lri=0x2
t=0x13bcf8
dt=0x4ad78
nod2=0x0
nod3=0x0
c=0x0
nod1=0x0
m=0x1
s=0x0
op=0x0
true=0x0
nod5=0x13a8b8
nod4=0x0
cp=0x13a630
si=0x1e
sugen(w=0x8,nn=0x13bcf8,n=0x136158)+0x160 /sys/src/cmd/8c/cgen.c:1701
t=0x0
nod1=0x1
nod2=0x2
nod0=0x0
l=0x3
r=0x3
nod3=0x0
nod4=0x3a214
h=0x3
p1=0x0
x=0x0
v=0x1
c=0x0
cgen64(nn=0x13bcf8,n=0x13b998)+0x1dcd /sys/src/cmd/8c/cgen64.c:1734
cmp=0x0
sh=0x0
d=0x0
optab=0x3fa74
args=0x39194
dr=0x1
l=0x136158
r=0x13bdd0
li=0x0
ri=0x0
lri=0x0
t=0x13bcf8
dt=0x0
nod2=0x0
nod3=0xdfff6738
c=0x0
nod1=0x0
m=0x0
s=0x0
op=0x0
true=0x0
nod5=0x18d5d
nod4=0x0
cp=0x0
si=0x0
sugen(w=0x8,nn=0x13bcf8,n=0x13b998)+0x160 /sys/src/cmd/8c/cgen.c:1701
t=0x70
nod1=0x2
nod2=0x5c
nod0=0x0
l=0xdfff66d4
r=0x138bc0
nod3=0x0
nod4=0x0
h=0x0
p1=0xdfff627c
x=0x0
v=0x1
c=0x0
cgen64(nn=0xdfff6f98,n=0x1361e8)+0x2bc6 /sys/src/cmd/8c/cgen64.c:2526
cmp=0x0
sh=0x0
d=0x13bcf8
optab=0x1732e
args=0x18d5d
dr=0x0
l=0x13b998
r=0x180d7
li=0x0
ri=0x0
lri=0x0
t=0x1b
dt=0xdfff6f98
nod2=0x1b070
nod3=0x0
c=0xdfff6490
nod1=0x8
m=0x0
s=0x1
op=0x0
true=0x0
nod5=0xdfff627c
nod4=0x44
cp=0x70
si=0x0
cgen(nn=0xdfff6f98,n=0x1361e8)+0x28d1 /sys/src/cmd/8c/cgen.c:1125
r=0x0
o=0x1b
curs=0x0
l=0x13b998
nod=0x70
nod1=0x0
hardleft=0x1
nod2=0x0
c=0x180c4
v=0xdfff6f98
nod3=0x135e80
nod4=0x180d7
onod=0x0
p1=0xdfff6f98
garg1(tn2=0xdfff6f50,f=0x1,fnxp=0xdfff6854,n=0x1361e8,tn1=0xdfff6f98)+0x1ca /sys/src/cmd/8c/txt.c:231
nod=0x0
garg1(tn2=0xdfff6f50,f=0x1,fnxp=0xdfff6854,n=0x136230,tn1=0xdfff6f98)+0x72 /sys/src/cmd/8c/txt.c:187
nod=0x0
garg1(tn2=0xdfff6f50,f=0x1,fnxp=0xdfff6854,n=0x136080,tn1=0xdfff6f98)+0x72 /sys/src/cmd/8c/txt.c:187
nod=0x0
garg1(tn2=0xdfff6f50,f=0x1,fnxp=0xdfff6854,n=0x135f60,tn1=0xdfff6f98)+0x72 /sys/src/cmd/8c/txt.c:187
nod=0x0
garg1(tn2=0xdfff6f50,f=0x1,fnxp=0xdfff6854,n=0x135ec8,tn1=0xdfff6f98)+0x72 /sys/src/cmd/8c/txt.c:187
nod=0xdfff67f4
garg1(tn2=0xdfff6f50,f=0x1,fnxp=0xdfff6854,n=0x135e38,tn1=0xdfff6f98)+0x72 /sys/src/cmd/8c/txt.c:187
nod=0x0
gargs(n=0x135e38,tn1=0xdfff6f98,tn2=0xdfff6f50)+0x98 /sys/src/cmd/8c/txt.c:160
regs=0x0
fnxargs=0x193bb
fnxp=0xdfff6858
cgen(nn=0xdfff718c,n=0x136278)+0x3763 /sys/src/cmd/8c/cgen.c:916
r=0x135e38
o=0x27
curs=0x0
l=0x135d60
nod=0x0
nod1=0x135fa8
hardleft=0x0
nod2=0x1
c=0x0
v=0x0
nod3=0x8
nod4=0x0
onod=0xdfff725c
p1=0xdfff718c
cgen(nn=0x0,n=0x1362c0)+0x121b /sys/src/cmd/8c/cgen.c:123
r=0x136278
o=0x6
curs=0x0
l=0x135d18
nod=0x0
nod1=0x136230
hardleft=0x0
nod2=0x1361e8
c=0xa
v=0x4ad78
nod3=0x1a32a
nod4=0x4ad78
onod=0x1c40b
p1=0x135d18
gen(n=0x1362c0)+0x126 /sys/src/cmd/cc/pgen.c:534
o=0x6
l=0x1
nod=0x0
rn=0x135c40
sp=0x4acb0
cn=0x14f2f
sbc=0x135ad0
snbreak=0x135c40
spb=0x0
scc=0x135c40
spc=0x135c40
sncontin=0x1ea68
f=0x135cd0
oldreach=0x14f2f
gen(n=0x136350)+0xb53 /sys/src/cmd/cc/pgen.c:515
o=0x2d
l=0x135cd0
nod=0x0
rn=0x4c7d8
sp=0x13b878
cn=0x14f2f
sbc=0x135690
snbreak=0x1ac1b
spb=0x1
scc=0x135720
spc=0x0
sncontin=0x1ea57
f=0x135720
oldreach=0x28
gen(n=0x136428)+0x5ed /sys/src/cmd/cc/pgen.c:421
o=0x26
l=0x1363e0
nod=0x0
rn=0x4c868
sp=0x13ae58
cn=0x14f2f
sbc=0xffffffff
snbreak=0x0
spb=0x13aee8
scc=0xffffffff
spc=0x13aea0
sncontin=0x0
f=0xffffff61
oldreach=0x14f2f
gen(n=0x136500)+0xbbb /sys/src/cmd/cc/pgen.c:524
o=0x2d
l=0x133a50
nod=0x0
rn=0x0
sp=0x13a3a8
cn=0x0
sbc=0x0
snbreak=0x0
spb=0x80000000
scc=0x0
spc=0x0
sncontin=0x0
f=0xdfff74b8
oldreach=0x1
codgen(nn=0x132668,n=0x132890)+0x195 /sys/src/cmd/cc/pgen.c:72
n1=0x1323e0
sp=0x136590
yyparse()+0x3dd /sys/src/cmd/cc/cc.y:1741
save1=0x0
save2=0x0
save3=0x0
save4=0x0
yystate=0x2
yychar=0xffffffff
yys=0x0
yyp=0xdfff7654
yyn=0xfffffc18
yypt=0xdfff76cc
w=0x0
n=0x0
s=0x0
compile(file=0xdfffefa8,ndef=0x0,defs=0x0)+0x2d0 /sys/src/cmd/cc/lex.c:291
ofile=0x732f6e2f
p=0xdfffecc9
incfile=0x3638332f
c=0x3
fd=0x0
av=0x0
i=0x0
opt=0x0
main(argv=0xdfffeef8,argc=0x1)+0x17b /sys/src/cmd/cc/lex.c:154
maxdef=0x0
ndef=0x0
defs=0x0
_argc=0x6f
_args=0xdfffef8a
p=0x0
np=0x0
nproc=0x0
c=0x0
nout=0x0
status=0x0
_main+0x31 /sys/src/libc/386/main9.s:16
acid:

My gut says this is a Plan 9 problem: something tickled a bug in 8c.
I hope someone here can diagnose the issue.

I needed to modify /sys/include/bio.h as well as
/sys/src/libbio/^(bgetc.c bputc.c) to get this far in the Go build; I
have nothing against adding Bgetle2(), Bgetle4(), Bputle2() and
Bputle4() to libbio, I do wish I had seen that coming.

We do seem to be losing ground to the Go developers, I have a feeling
that it is going to be hard to catch up.

++L

PS: One irritant I would gladly get rid of is the sheer number of
warnings that are being produced:

cmd/cc
warning: /n/shackle/go/src/cmd/cc/y.tab.c:1785[/n/shackle/go/src/cmd/cc/y.tab.c:3489] result of operation not used
warning: /n/shackle/go/src/cmd/cc/y.tab.c:1785[/n/shackle/go/src/cmd/cc/y.tab.c:3489] result of operation not used
warning: /n/shackle/go/src/cmd/cc/y.tab.c:1791[/n/shackle/go/src/cmd/cc/y.tab.c:3495] result of operation not used
warning: /n/shackle/go/src/cmd/cc/y.tab.c:1791[/n/shackle/go/src/cmd/cc/y.tab.c:3495] result of operation not used

as an example. I haven't quite figured out what triggers these, nor
how to eliminate them.

[erik quanstrom]

> My gut says this is a Plan 9 problem: something tickled a bug in 8c.
> I hope someone here can diagnose the issue.

sure. this is not a bug per ce. it's a limitation of 8c's technique
for registerizing vlongs given the restricted register set of the 386.

8c takes an initial stab at registerizing expressions. if it needs
more than AX-DI, it can't be compiled without breaking down the
expressions a bit. spilling is not implemented at this level.

since even ghostscript doesn't get into this state, i'd be interested
in the line of code (and types of the variables) that hits this fatal
condition.

imho the diag() abort() should be replaced with a fatal(), since
-X will give anyone interested a broken process to debug, and leave
anyone not interested alone.

> I needed to modify /sys/include/bio.h as well as
> /sys/src/libbio/^(bgetc.c bputc.c) to get this far in the Go build; I
> have nothing against adding Bgetle2(), Bgetle4(), Bputle2() and
> Bputle4() to libbio, I do wish I had seen that coming.
>
> We do seem to be losing ground to the Go developers, I have a feeling
> that it is going to be hard to catch up.

perhaps chasing the tip isn't going to work.

- erik

[lu...@proxima.alt.za]

> since even ghostscript doesn't get into this state, i'd be interested
> in the line of code (and types of the variables) that hits this fatal
> condition.

I'll see if I can track down more details, I'm relieved there are
others out there who can fathom out these situations (and show some
concern)...

++L

[lu...@proxima.alt.za]

> since even ghostscript doesn't get into this state, i'd be interested
> in the line of code (and types of the variables) that hits this fatal
> condition.

Here it is, "before" and "after" I applied some trivial "simplification":

/*
for(i=0, j=(stkptrsize-stkzerosize)/widthptr*2; i<stkzerosize; i+=widthptr, j+=2)
if(bvget(bv, j) || bvget(bv, j+1))
p = appendp(p, AMOVL, D_CONST, 0, D_SP+D_INDIR, frame-stkzerosize+i);
*/
i = 0;
j = (stkptrsize-stkzerosize)/widthptr*2;
while (i < stkzerosize) {
int f = frame - stkzerosize + i;
if(bvget(bv, j) || bvget(bv, j+1)) {
p = appendp(p, AMOVL, D_CONST, 0, D_SP+D_INDIR, f);
}
i += widthptr;
j += 2;
}

around line 40 in $GOROOT/src/cmd/8g/ggen.c.

Thank you, Erik, for your invaluable input, it seems to work now.

++L

[erik quanstrom]

> /*
> for(i=0, j=(stkptrsize-stkzerosize)/widthptr*2; i<stkzerosize; i+=widthptr, j+=2)
> if(bvget(bv, j) || bvget(bv, j+1))
> p = appendp(p, AMOVL, D_CONST, 0, D_SP+D_INDIR, frame-stkzerosize+i);
> */
> i = 0;
> j = (stkptrsize-stkzerosize)/widthptr*2;
> while (i < stkzerosize) {
> int f = frame - stkzerosize + i;
> if(bvget(bv, j) || bvget(bv, j+1)) {
> p = appendp(p, AMOVL, D_CONST, 0, D_SP+D_INDIR, f);
> }
> i += widthptr;
> j += 2;
> }
>
> around line 40 in $GOROOT/src/cmd/8g/ggen.c.
>
> Thank you, Erik, for your invaluable input, it seems to work now.

no problems. is this the minimum amount of reorginization necessary?

- erik

[Nick Owens]

hello 9fans and gophers,

i have been using go on 9front for a while now. however, an issue
with 8c's inclusion mechanism was recently introduced.

the commit was https://codereview.appspot.com/12568043 which assumes
that includes will be resolved relative to the file that included them,
not the wd of the compiler. you can see in the comments a bit of the
discussion. http://9.offblast.org/stuff/cfc3eab6195a shows this problem
more explicitly. d881cb1ffc14 is the most recent commit that i use now.

do you fellows have any idea how to resolve this? is this go or plan 9's
'fault'?

nick

[Rob Pike]

I'm pretty sure C defines the include path to be relative to the file
that includes it. The compiler's working directory should be
irrelevant. I'm also pretty sure Plan 9's compiler gets this right, or
at least used to. So more information is required.

-rob

[erik quanstrom]

that still works, otherwise the kernel would not compile.

- erik

[Nick Owens]

the trouble here is that go's src/libmach/8obj.c has '#include
"../cmd/8l/8.out.h"', and 8.out.h now has the newly added '#include
"../ld/textflag.h"'.

i see now that the kernel source has an instance of this, in
/sys/src/9/pc: 'fns.h:1: #include "../port/portfns.h"', but i'm not sure
how that is treated differently from this situation.

i did a small test, and made $home/bin/rc/8c which forces the -p flag of
8c to invoke cpp. when doing ./make.rc in go with this wrapper, the
include appears to be resolved correctly.

fwiw, the standard does not define the mechanism for includes to be
found at all, only that it is implementation-specific [1].

nick

[1] http://www.iso-9899.info/n1256.html#6.10.2

[erik quanstrom]

> the trouble here is that go's src/libmach/8obj.c has '#include
> "../cmd/8l/8.out.h"', and 8.out.h now has the newly added '#include
> "../ld/textflag.h"'.
>
> i see now that the kernel source has an instance of this, in
> /sys/src/9/pc: 'fns.h:1: #include "../port/portfns.h"', but i'm not sure
> how that is treated differently from this situation.

it is different because -I../port is part of CFLAGS.

i've just verified that the plan 9 c compilers interpret relative
paths relative to the original source file, not any included files,
but -p interprets relative to the file doing the including.
imo the compilers should be fixed, but it might require a few
fixes. the easiest (smallest delta) solution would be for
8.out.h to include "../../cmd/ld/textflag.h" instead of "../ld/textflag.h".

i suppose this is just another reason not to include include files. ☺

- erik