> I did, and to my surprise, AX is 0, even though I set it properly in
> the loader. It appears as if Linux is setting AX to 0 sometime after
> the loader finishes, but before the executable begins. All other
> registers, however, are preserved (eip being the most important).
The zero you se
Hi Russ,
You should print AX after every instruction too, to see if
you've actually set it up the way you think you did.
I did, and to my surprise, AX is 0, even though I set it properly in
the loader. It appears as if Linux is setting AX to 0 sometime after
the loader finishes, but before
> I set EAX before starting the executable, but still no luck :(
> On Plan 9, for /bin/mk:
>
> acid: symbols("_tos")
> _tos D 0x00016084
> acid: mem(0x00016084, "X")
> 0xdfffefc8
>
> I'm probing address 0x16084 on linux after every instruction (using
> ptrace's singlestep), and i
So I have to allocate 56 bytes (sizeof(Tos) on 386) of space above
the
top of stack (before copying argc and argv) and set AX to that
address, correct?
Yes. And you need to maintain it.
At the very least you need to initialize tos->pid
and update it on return from rfork.
I set EAX before st
> The clone(2) system call in linux allows for creation of child
> processes that share address space with its parent, with the exception
> of the stack segment. I believe that should do?
>Wouldn't the CLONE_VM flag do this?
no.
Linux shares the stack segment too: the underlying system call
On Thu, 2008-05-08 at 13:24 -0400, Russ Cox wrote:
> > So I have to allocate 56 bytes (sizeof(Tos) on 386) of space above the
> > top of stack (before copying argc and argv) and set AX to that
> > address, correct?
>
> Yes. And you need to maintain it.
> At the very least you need to initial
> So I have to allocate 56 bytes (sizeof(Tos) on 386) of space above the
> top of stack (before copying argc and argv) and set AX to that
> address, correct?
Yes. And you need to maintain it.
At the very least you need to initialize tos->pid
and update it on return from rfork.
> The clone(2
Hi Russ,
Thanks for your response!
When a Plan 9 binary first starts running, the system
call return register (AX in this case) contains a pointer
to the Tos structure. /sys/src/libc/386/main9.s
saves that value in the global variable named _tos.
It sounds like you are not setting AX correctly
Tos is a clumsy hack. It refers to a structure stored
at the top of the stack that is used to pass data
between the kernel and user space without system calls.
See /sys/include/tos.h.
When a Plan 9 binary first starts running, the system
call return register (AX in this case) contains a pointer
