Mail Archives: djgpp/1997/04/15/04:48:00
On Mon, 14 Apr 1997, Christopher Croughton wrote:
> > If you are willing to wait until the child exits, why can't
> > you just spawn the same program, like so:
>
> Try doing it when the bit that does the fork is down in 10 levels
> of function calls, and depends on gobal variables being set correctly
> by the time it gets there. In the case of tcsh, that includes all
> the aliases and local shell variables, not just the environment which
> is passed to the child.
This problem is only relevant to a program that forks itself. Most
programs call `execXX' right after forking, which is functionally the
same as `spawnXX'.
I think the approach that you had in mind (to change the DJGPP startup
code) is too complex. I can think about two other possibly simpler
ways of making this happen.
1) Look how this is done in the DJGPP port of Bash. I don't
know the answer, and therefore cannot tell how well it suits you, but
it *does* work.
2) Create an image of the program with all the variables
frozen at their values, then invoke that program. That is how the
Emacs executable is created when you build Emacs, so you can look at
the Emacs sources (filename unexec.c) to see how this works. In
Emacs, the image is actually written to a disk file, but going from
there to a memory move followed by passing the control to that image
shouldn't be very hard. The `v2loadimage' function (see djlsr201.zip,
file src/debug/common/v2load.c), used by all DJGPP debuggers, is a
working example of how an image is loaded and control passed to it.
- Raw text -