Mail Archives: djgpp-workers/2000/06/28/17:00:36
> 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
- Raw text -