lbr@holos0.uucp (Len Reed) (03/05/91)
I procurred undump, and have tried it on NCR Tower V.2 and V.3 systems, and an AT&T V.3 386 system. (Perl patch level 44.) All systems worked fine except that the stdin, stdout, and stderr handles don't work right in the resurrected executable. This is true of perl and of a trivial test program I wrote. My test program shows that descriptor I/O to 0, 1, and 2 works fine, though. I changed perly.c so that when it discovers it is running an undumped script it fcloses these three streams and the opens them using fdopen: fclose(stdin); fdopen(0, "r"); fclose(stdout); fdopen(1, "w"); fclose(stderr); fdopen(2, "w"); This goes right before the "goto just_doit". My guess is that stream I/O somehow depends upon some .bss data that is not zero in the undumped script. (Undump puts the entire .bss into the .data area.) (Zeroing out _iob[] didn't fix it.) Obviously there's something I've done wrong; since it's hard to miss when STDOUT is being thrown away. Either I have a bad undump (though I'm not sure how it could deal with this problem) or the systems I'm running on have stream I/O implemented in an unusual way. Ideas? -- Len Reed Holos Software, Inc. Voice: (404) 496-1358 UUCP: ...!gatech!holos0!lbr