> /*
> for(i=0, j=(stkptrsize-stkzerosize)/widthptr*2; i 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
> 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;
On Sat, Aug 31, 2013 at 10:23 AM, James A. Robinson <
j...@highwire.stanford.edu> wrote:
> I see the entire text of the window get selected.
> I had assumed that if I then read addr that I would
> get back two numbers, 0 and the final byte offset
> of the file (it is a non-zero length file).
>
> H
Say I have an acme window with a $winid of 2.
If I type the following commands:
$ echo -n , | 9p write acme/2/addr
$ echo dot=addr | 9p write acme/2/ctl
I see the entire text of the window get selected.
I had assumed that if I then read addr that I would
get back two numbers, 0 and the final byte
> 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
> 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 registerizi
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/
