Date:	Thu, 19 Dec 1996 11:32:54 +0100 (MET)
From:	Robert Hoehne <robert DOT hoehne AT mathematik DOT tu-chemnitz DOT de>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc:	DJGPP workers <djgpp-workers AT delorie DOT com>
Subject:	Re: strip reverts the stub to default
In-Reply-To:	<Pine.SUN.3.91.961219080758.24763D-100000@is>
Message-Id:	<Pine.HPP.3.95.961219112253.7752B-100000@newton.mathematik.tu-chemnitz.de>
Mime-Version:	1.0

On Thu, 19 Dec 1996, Eli Zaretskii wrote:

> If you run `strip' on a .exe program, the stub info is reverted to  
> default values.  This is BAD (IMHO), since people don't expect the 
> program to change when you strip it.  I understand why is it happening 
> (the stub is hard-coded inside the bfd library used by Binutils), but I 
> submit that we should try to change the effect of this in the case of 
> `strip'.
For this I must take a look at the sources, if it is possible, to
get from anywhere some information if there is an existing stub
when creating a new bfd-object, probably this have to changed
in 'objcopy.c' but I must see.

> that the entire file, not only the stub part, is being read in this case. 
> Is this correct, or am I missing something? 
That's correct. But the change for this would be simple, if I (we)
can assume, the the stub has a fixed size or the size of the stub can
be computed from the stub itself.

Ah!! Now I looked in 'coff-go3.c' and saw, that the stub-size can
be computed from the the exe-header. I think I will do the patch
and send it in the next days.

> Robert, can you please see if there's a simple way to prevent this from 
> happening?  Thanks.
See above. If you can't wait for my patch, look in 'coff-go3.c' in
function 'go32_stubbed_coff_mkoobject()'. There I'm "computing" the
size of the stub by the assumption, that it is equal to the filesize.

Robert

- Raw text -