[9fans] Alef - run time error

[9fans] Alef - run time error

[lucio]

These values are declared in the library (alef/lib/386/run.h) source code:

/* Runtime data structures */

enum
{
	Ptab		= 0x7fff5000,	/* Private stack */
	Execstk		= 0x7f001000,	/* Exec stack linkage area */
};

The runtime fails:

8.sieve 6302: suicide: sys: trap: fault write addr=0x7fff5000 pc=0x00001c2d

so I presume that new values and hopefully not major surgery, are
called for.  Can anyone help?  Also, are there analogous values in the
other platforms (power, sparc, mips) that require attention?

++L

Re: [9fans] Alef - run time error

[Russ Cox]

On 3/17/07, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> These values are declared in the library (alef/lib/386/run.h) source code:
>
> /* Runtime data structures */
>
> enum
> {
>         Ptab            = 0x7fff5000,   /* Private stack */
>         Execstk         = 0x7f001000,   /* Exec stack linkage area */
> };
>
> The runtime fails:
>
> 8.sieve 6302: suicide: sys: trap: fault write addr=0x7fff5000 pc=0x00001c2d
>
> so I presume that new values and hopefully not major surgery, are
> called for.  Can anyone help?  Also, are there analogous values in the
> other platforms (power, sparc, mips) that require attention?

the pc address space got bigger in 2005 so that programs could
use more than 2gb of memory.  the top of the stack is now
0xdffff000 instead of 0x7ffff000, so if you s/0x7/0xd/ you
will probably be okay.  it would be even better if _main looked
at its stack pointer and anded off some bits, so that those
weren't hard-coded.

power didn't move, and mips and sparc aren't in the main tree anymore.

russ

Re: [9fans] Alef - run time error

[lucio]

> the pc address space got bigger in 2005 so that programs could
> use more than 2gb of memory.  the top of the stack is now
> 0xdffff000 instead of 0x7ffff000, so if you s/0x7/0xd/ you
> will probably be okay.
> 
Thank you very much, that worked fine, which is OK at least to test
the compiler.

>   it would be even better if _main looked
> at its stack pointer and anded off some bits, so that those
> weren't hard-coded.
> 
If you know a quick way to inspect the stack pointer, rather than me
having to dig for it, I'll fix it with pleasure.  Alternatively, if
you know where I ought to look, please point me there.  Oh, yes,
please also explain what "and"ing off a few bits means, unless you
mean that by trimming the incoming stack pointer I'll get a reasonable
value for a private copy.  That would make just about as much sense as
I can grasp.

Mind you, I presume the "C" runtime plays such a trick if you suggest
it, should I look at those sources and where are they, as specific as
you can be?

> power didn't move, and mips and sparc aren't in the main tree anymore.

I can't test any of them, unfortunately, but I'll make a note of your
comments.  It saddens me that we're losing scope like this, but it's
inevitable, I suppose.

Thanks again, Russ.

++L

Re: [9fans] Alef - run time error

[erik quanstrom]

On Sat Mar 17 13:23:51 EDT 2007, lucio@proxima.alt.za wrote:
> > the pc address space got bigger in 2005 so that programs could
> > use more than 2gb of memory.  the top of the stack is now
> > 0xdffff000 instead of 0x7ffff000, so if you s/0x7/0xd/ you
> > will probably be okay.
> > 
> Thank you very much, that worked fine, which is OK at least to test
> the compiler.
> 
> >   it would be even better if _main looked
> > at its stack pointer and anded off some bits, so that those
> > weren't hard-coded.
> > 
> If you know a quick way to inspect the stack pointer, rather than me
> having to dig for it, I'll fix it with pleasure.  



this c program will tell you where c leaves the tos.

	#include<u.h>
	#include<libc.h>
	void
	main(void)
	{
		char *tos;
		print("%p\n", &tos);
		exits("");
	}

for me this prints dfffef68. so there are 0x98 bytes taken
from the top of the stack before main starts.


> Alternatively, if
> you know where I ought to look, please point me there.  Oh, yes,
> please also explain what "and"ing off a few bits means, unless you
> mean that by trimming the incoming stack pointer I'll get a reasonable
> value for a private copy.  That would make just about as much sense as
> I can grasp.

i'm pretty sure that's what he's after.  /sys/src/libc/386/main9.s subtracts
a constant from _tos.

- erik

Re: [9fans] Alef - run time error

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 96 bytes --]

there is also some library support for per-process data,
that could now be used.  see exec(2)

[-- Attachment #2: Type: message/rfc822, Size: 4533 bytes --]

From: "Russ Cox" <rsc@swtch.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
Subject: Re: [9fans] Alef - run time error
Date: Sat, 17 Mar 2007 12:19:52 -0400
Message-ID: <ee9e417a0703170919g2a2b6427p98afa49fc19ad0c6@mail.gmail.com>

On 3/17/07, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> These values are declared in the library (alef/lib/386/run.h) source code:
>
> /* Runtime data structures */
>
> enum
> {
>         Ptab            = 0x7fff5000,   /* Private stack */
>         Execstk         = 0x7f001000,   /* Exec stack linkage area */
> };
>
> The runtime fails:
>
> 8.sieve 6302: suicide: sys: trap: fault write addr=0x7fff5000 pc=0x00001c2d
>
> so I presume that new values and hopefully not major surgery, are
> called for.  Can anyone help?  Also, are there analogous values in the
> other platforms (power, sparc, mips) that require attention?

the pc address space got bigger in 2005 so that programs could
use more than 2gb of memory.  the top of the stack is now
0xdffff000 instead of 0x7ffff000, so if you s/0x7/0xd/ you
will probably be okay.  it would be even better if _main looked
at its stack pointer and anded off some bits, so that those
weren't hard-coded.

power didn't move, and mips and sparc aren't in the main tree anymore.

russ