alex@umbc3.UMD.EDU (Alex S. Crain) (10/06/88)
Mike Ditto's unstrip.c program that was posted a little while ago has the nasty habit of zeroing out the entry point and executable flags in the executable. Here is a patch to fix that... Replace the end of readhdrs() which looks like [...] return 0; } add these lines [...] + rewind(fp); + + filehdr.f_flags |= F_EXEC; + fwrite((char *)&filehdr, sizeof filehdr, 1, fp); + + aouthdr.entry = 0x80000; + fwrite((char *)&aouthdr, sizeof aouthdr, 1, fp); + return 0; }-- :alex. Systems Programmer nerwin!alex@umbc3.umd.edu UMBC alex@umbc3.umd.edu
ditto@cbmvax.UUCP (Michael "Ford" Ditto) (10/07/88)
In article <1225@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes: > Mike Ditto's unstrip.c program that was posted a little while ago >has the nasty habit of zeroing out the entry point and executable flags >in the executable. Here is a patch to fix that... It's ld -r that resets F_EXEC and zeroes the entry address; there's no way to find out what it was when unstrip is run. Alex's patch to make it 0x80000 is fine for all Unix PC executables I've seen, though. I never noticed the problem before because I never actually tried to execute the output of unstrip; I only used it for adb'ing. -- -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@kenobi.cts.com - The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford 2nd Edition, June, 1972. ditto@cbmvax.commodore.com