ant@mks.com (Anthony Howe) (04/19/91)
I've been hunting high and low in the DevDocs for information on
how a parent process finds the return code of the child process.
Now I know Pexec() returns a value when it executes a program, but
I only use Pexec() to load, and I initiate the program through
separate means.
Q: What I want to know is the return code passed back in D0, on the
stack, or in some global system location? Is the return code
available at the time of the call to the Terminate Handler?
I'm trying to make mods to the Sozobon Debugger to handle printing
the return values before it exits.
Q: If I've used Pexec() to load a program and I'm handling the
execution of parts of that program. How can I tell the system
to terminate that child process. Basically I want a kill() or
a ptrace(PT_KILL_PID, child, 0, 0) so that I can add a restart
command.
-ant
--
__ "So many pedestrians
_ . .-|- / _\ . . |_ _. _ _ . . So little time."
(_\ |\| | |(_/ |\/| |\ _\ o (_ (_) |\/| bumber sticker
Mortice Kern Systems Inc. 35 King St. N., Waterloo, Ontario, Canada, N2L 6W9apratt@atari.UUCP (Allan Pratt) (04/26/91)
ant@mks.com (Anthony Howe) writes: >I've been hunting high and low in the DevDocs for information on >how a parent process finds the return code of the child process. >Now I know Pexec() returns a value when it executes a program, but >I only use Pexec() to load, and I initiate the program through >separate means. Sigh. I guess there's nothing much to say about this... Are you SURE you can't use Pexec to execute the program, too? Try mode 4, then Mfree the environment and basepage (in that order) that were created when you used Pexec mode 3 or 5 (whichever you used). Starting with TOS 1.4, you can use Pexec mode 6: mode 3 plus mode 6 equals mode zero. The return code from mode 6 will be the return code from the process. >Q: What I want to know is the return code passed back in D0, on the > stack, or in some global system location? Is the return code > available at the time of the call to the Terminate Handler? > I'm trying to make mods to the Sozobon Debugger to handle printing > the return values before it exits. The return code is not available at the terminate handler. The return code is the argument to Pterm() or Ptermres(), or zero for Pterm0(). If you want, I guess you could catch those calls and squirrel away the return code before passing the call on to GEMDOS. >Q: If I've used Pexec() to load a program and I'm handling the > execution of parts of that program. How can I tell the system > to terminate that child process. Basically I want a kill() or > a ptrace(PT_KILL_PID, child, 0, 0) so that I can add a restart > command. You have to execute a Pterm() call while the process is the "current process" as far as GEMDOS is concerned. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
ant@mks.com (Anthony Howe) (05/01/91)
apratt@atari.UUCP (Allan Pratt) writes: >ant@mks.com (Anthony Howe) writes: >>I've been hunting high and low in the DevDocs for information on >>how a parent process finds the return code of the child process. >>Now I know Pexec() returns a value when it executes a program, but >>I only use Pexec() to load, and I initiate the program through >>separate means. >> >Sigh. I guess there's nothing much to say about this... Are you SURE you >can't use Pexec to execute the program, too? Try mode 4, then Mfree the >environment and basepage (in that order) that were created when you used >Pexec mode 3 or 5 (whichever you used). Starting with TOS 1.4, you can >use Pexec mode 6: mode 3 plus mode 6 equals mode zero. The return code >from mode 6 will be the return code from the process. I should say that I'm working on a debugger (SZADB) which means I can't just load-and-go. I was trying to figure out how DB started a child process for debugging. What I've divined so far with the aid of DB and SYSMON (and guessed) is that DB does a load-and-go from its user stack but somehow manages to convince GEM to trap on the first instruction and so re-enter DB in as though a break point occured in the supervisor stack (which is not the same as the usp). Later I assume, when the program terminates, it returns from the Pexec() on the user stack and so receives the return code. Provided the above is somewhat correct, how does DB forces GEMDOS to trap on that first instruction by doing only a Load-and-Go (in a legal manner). I suppose I could do the Pexec() Load-only, plant the breakpoint trap, then do the Pexec() Go on the user stack, receive the trap on the super stack and work in the debugger as normal. Later when the program terminates from the Pexec() Go, I fall into the debugger on the user stack with the return code. >>Q: What I want to know is the return code passed back in D0, on the >> stack, or in some global system location? Is the return code >> available at the time of the call to the Terminate Handler? >> I'm trying to make mods to the Sozobon Debugger to handle printing >> the return values before it exits. > >The return code is not available at the terminate handler. The return >code is the argument to Pterm() or Ptermres(), or zero for Pterm0(). >If you want, I guess you could catch those calls and squirrel away the >return code before passing the call on to GEMDOS. This one I figured out. It is possible to find the return code from the terminate handler. However I doubt I'll end up using this method. terminate_handler: move usp, a0 ;grab user's stack pointer move.w 4(a0), d0 ;get GEMDOS function number bnz.s .1 clr.w child_return ;Pterm0() - return code 0 rts .1: cmpi.w #$4c, d0 ;check for Pterm() bne.s .2 move.w 6(a0), child_return ;grab the return code .2: rts -ant -- __ "So many pedestrians _ . .-|- / _\ . . |_ _. _ _ . . So little time." (_\ |\| | |(_/ |\/| |\ _\ o (_ (_) |\/| bumber sticker Mortice Kern Systems Inc. 35 King St. N., Waterloo, Ontario, Canada, N2L 6W9