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
Content-Type: TEXT/PLAIN; charset=US-ASCII

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