From: "Mark E." To: Eli Zaretskii , djgpp-workers AT delorie DOT com Date: Wed, 28 Jun 2000 17:01:04 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: is it possible to use strip option in call to compiler (fwd) Message-ID: <395A2F50.7422.1F2BA3@localhost> References: <39595137 DOT 6430 DOT 5D4FCB AT localhost> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Reply-To: djgpp-workers AT delorie DOT com > Did you invoke ld with or without --strip? with it. > > I think I only saw the problem with "gcc -s". If I don't use -s, but > instead strip the COFF image and then stubify, the garbage never appears. I can't explain the garbage yet, but I think I can explain the extra 2K. Compile a trivial program to an object file. Now compile that program to an executable, but leave out the '.exe': gcc -o trivial trivial.o strip trivial.exe and you will find that trivial and trivial.exe are exactly the same size. If you use ld and bypass stubify and djgpp.djl, you will also get just about the same file size. I believe that ld can add the stub without adding to the file size because it knows the .text section starts at a location (at 0x1000+SIZEOF_HEADERS according to the linker script) which doesn't interfere with where the stub is to go. stubify on the other hand doesn't know anything about section placement, alignment, etc. It just writes out the stub and then blindly copies the image. When you run strip on a stubified file, it knows enough about placement and alignment (though I'm sure not like ld does) to get rid of the 2K. I suspect strip writes out the stripped file based on the section's vma. Stubify doesn't touch this, since it blindly writes out the coff image. My suspicion on strip using the vma is based using 'objdump --header' on an executable stubbed with stubify. An executable produced by stubify will have a the vma is 2K (0x0800) lower than the file offset. As for the garbage, it does seem like the seek problem as DJ suggested, but I'll try look at the code to make sure of it. Putting readable garbage in the executable is not acceptable IMO no matter what the cause. Mark