Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: [9fans] Building Go/386

1,062 views
Skip to first unread message
Message has been deleted

erik quanstrom

unread,
Aug 31, 2013, 11:11:32 AM8/31/13
to
> 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

unread,
Aug 31, 2013, 1:09:57 PM8/31/13
to
> 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

unread,
Aug 31, 2013, 2:12:38 PM8/31/13
to
> 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

unread,
Aug 31, 2013, 5:16:34 PM8/31/13
to
> /*
> 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

unread,
Sep 2, 2013, 2:15:54 PM9/2/13
to
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

unread,
Sep 2, 2013, 4:50:07 PM9/2/13
to
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

unread,
Sep 2, 2013, 5:51:15 PM9/2/13
to
that still works, otherwise the kernel would not compile.

- erik

Nick Owens

unread,
Sep 2, 2013, 6:08:56 PM9/2/13
to
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

unread,
Sep 2, 2013, 8:28:52 PM9/2/13
to
> 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

0 new messages