[9fans] Alef - run time error - Plan9

This is a discussion on [9fans] Alef - run time error - Plan9 ; 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: ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: [9fans] Alef - run time error

  1. [9fans] Alef - run time error

    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


  2. Re: [9fans] Alef - run time error

    On 3/17/07, 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

  3. Re: [9fans] Alef - run time error

    > 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


  4. Re: [9fans] Alef - run time error

    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
    #include
    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

  5. Re: [9fans] Alef - run time error

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


+ Reply to Thread