Mail Archives: djgpp-workers/2000/05/29/04:50:33
On Sun, 28 May 2000, Charles Sandmann wrote:
> The nesting 3 level deep sequence:
> redir /make /echo2
> seems to be stable
>
> The nesting 3 level deep sequence:
> redir / gcc -c -O2 *.c
> seems to be stable
>
> The nesting 3 level deep sequence:
> go32-v2 \djgpp\gcc.exe -O2 -c @c.inp
> seems to be stable (it won't take *.c for some reason, and this is 3 level
> nesting - does go32-v2 unhook interrupts?)
Yes, go32-v2 also toggles all exceptions before it longjmp's to the
child's code. This was added in v2.02, to avoid leaving the keyboard
and other interrupts pointing to the void when the child exits (since
the execution thread never comes back to go32-v2).
As for the problem with *.c, I think this is expected: go32-v2 doesn't
do a very clean job in emulating a shell for the child program. redir
does, but that took some very non-trivial code, added in v2.03.
> So, maybe the unhooking helps if it is done at the top level?
Well, to test this hypothesis, how about running the full libc build
under redir? Library build is very deeply nested (I think it gets up
to 4 or 5 levels of nested invocations), and runs lots of programs, so
it should be a good test.
> > > FAULT ->77e89b01 e9d2030300 jmp SetThreadContext+0x46 (77eb9ed8)
> >
> > It seems to crash when it jmp's to one of its own routines. How can that
> > happen?
>
> It could be due to a code segment limit violation, or a page fault.
Wrong CS was my first guess, but that looks like a remote possibility
(if they cannot restore CS, what *can* they do? ;-). And the
instruction just before that calls a similar address, albeit via DS,
for some reason...
- Raw text -