Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <3B5C9578.4090601@ece.gatech.edu>
Date: Mon, 23 Jul 2001 17:22:00 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713
X-Accept-Language: en-us
MIME-Version: 1.0
To: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: cygwin-apps AT cygwin DOT com
Subject: Re: ld non-relocatable
References: <00de01c1133a$23521f60$806410ac AT local> <00fd01c11340$d0a51900$806410ac AT local>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Robert Collins wrote:

> Concept-patch. It removes the .reloc section quite happily.
> 
> I don't know whether this will produce faster code - as all the relocation
> logic is presumably still in the machinecode. However, it should guarantee
> fork() :].
> 
> Charles - care to add this to your testing pile? The new
> parameter --no-relocate needs to be added to the cygwin .dll link line (for
> somewhat obvious reasons :]).
> 


No good.  The --no-relocate switch has exactly the same effect as 
'objcopy -R .reloc': they both strip ONLY the relocation info and not 
the debugging stuff.  However, when you do that, and try to run an 
executable, you get the following popup:

The application or DLL <path to dll> is not a valid Windows image. 
Please check this against your installation diskette.

There seems to be some tie between the debug info and the reloc stuff -- 
you need both or neither, it seems.  Since 'strip -g' will remove the 
debugging info (but not symbols nor reloc), it is interesting that the 
following works:

original cygz.dll (contains symbols, debugging info, and .reloc)
strip -g cygz.dll (removes ONLY debugging info)
objcopy -R .reloc cygz.dll (removes ONLY .reloc info)
executables still work.

original cygz.dll (contains symbols, debuggin info, and .reloc)
strip -R .reloc cygz.dll (removes symbols, AND debugging info, AND .reloc)
executables still work.

original cygz.dll (contains symbols, debuggin info, and .reloc)
objcopy -R .reloc cygz.dll (removes ONLY .reloc info)
executables break
strip -g cygz.dll (removes ONLY debug info; symbols are still there)
executables work

Note that these behaviors are the same if you start with a 
--no-relocations dll:

cygz.dll (+symbols, +debuggin, but --no-relocations flag was used)
executables break
strip -g cygz.dll (removes ONLY debug info; symbols are still there)
executables work

I think -- and this is just a guess -- that somehow the debugging info 
is tied in to the relocations. In the same way that there is no point to 
stripping symbols from a dll but leaving the debug info.  That is, using 
strip you can, with standard options (-g, -S, etc):

remove symbols and debug info
remove just debug info
but can't
remove just symbols and leave debug info

In this example, it makes sense -- what goes is the debug info if the 
symbol table is missing?   It can't be used.

I wonder if the .reloc stuff is similar...no, that can't be true, based 
on my earlier experiments with MSVC/link's /fixed switch.  The DLL's 
generated that way HAVE symbols.  HAVE debug info. DON'T have relocs. 
But executables work.

Hmmm...

BTW, all tests above were performed with --disable-auto-imports.  One 
thing at a time.

--Chuck