Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!uxh.cso.uiuc.edu!archetyp
From: archetyp@uxh.cso.uiuc.edu (Joseph R Pickert)
Newsgroups: comp.os.minix
Subject: Re: fixing strip (was: Re: MacMinix: strip causes system bomb)
Message-ID: <1990Nov27.160735.3782@ux1.cso.uiuc.edu>
Date: 27 Nov 90 16:07:35 GMT
References: <9011192110.AA15043@decpa.pa.dec.com> <1477@ria.ccs.uwo.ca>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 34

webber@csd.uwo.ca (Robert E. Webber) writes:

>In article <9011192110.AA15043@decpa.pa.dec.com> cranston@guru.dec.com (Scott Cranston) writes:
>>strip(1) on MacMinix does not work.  The origional flavor before the a.out.h
>>patch that Joe Pickert posted (part of ps(1) fixes) would not recognize
>>a file as an executable.  After recompiling strip using the new a.out.h
>>it now runs.  However, when I recompile a command and then strip it I get
>>a SYSTEM BOMB ID=10.
>> 
>>Any ideas or fixes?

>A less drastic way of observing the problem is that nm on a normal executable
>reports the symbol table, on one of the supplied executables, it reports
>nothing, but on a stripped executable it reports
>    can't read symbol table
>Insertion of print messages into nm shows the following behavior:
>   cp nm bin/nm
>   nm bin/nm >/dev/null
>does an lseek to location 6782 and then reads a table of size 1808
>   ls -l bin/nm
>reports a file size of 8860
>   strip bin/nm
>   nm bin/nm >/dev/null
>does an lseek to location 6782 and then reads a table of size 1808.
>however, since
>   ls -l bin/nm
>reports that the file is now 7020 bytes long, the above read only reads
>238 bytes and then reports that it can't read the symbol table since the
>value from read is less than the length to read.

I am aware of these problems.  The ultimate cause is the a.out.h file.
I will post a new one soon.

Joe Pickert