Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Message-ID:	<4151E22C.3020209@cwilson.fastmail.fm>
Date:	Wed, 22 Sep 2004 16:35:56 -0400
From:	Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 MultiZilla/1.6.4.0b
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Cc:	Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>, libtool-patches AT gnu DOT org
Subject:	Re: cygwin, libtool, dlpreopen, and .rdata
References:	<41511C3F DOT 7080003 AT cwilson DOT fastmail DOT fm> <Pine DOT CYG DOT 4 DOT 58 DOT 0409221012570 DOT 2736 AT fordpc DOT vss DOT fsi DOT com>
In-Reply-To:	<Pine.CYG.4.58.0409221012570.2736@fordpc.vss.fsi.com>

Brian Ford wrote:
> On Wed, 22 Sep 2004, Charles Wilson wrote:
> 
> 
>>[cygwin list: I'm CC'ing this so that it goes into the archives, but
>>it's pretty technical about the innards of libtool...]
> 
> 
> This doesn't seem libtool related at all to me (other than it's a gcc bug
> that affects libtool).

Oh, except for the fact that there's a libtool patch included in the 
email.  Besides, it's not really a gcc bug; it's a new feature, that 
does exactly what it should do -- except that it shouldn't be used in te 
way that libtool is forcing it to be used.  const "variables" exported 
from a DLL absolutely should go in .rdata[1].  Const "variables" in an 
application absolutely should go in .rdata.  No problems; and many benefits.

It's when an application declares a variable const, which is supposed to 
hold the address of a DATA item imported from a DLL, that is the problem 
-- because, thanks to the behind-the-scenes runtime-reloc stuff, *it 
isn't really const*.  In that case, it should not be declared const.

Libtool creates a little file that declares a const "variable" which 
holds an address that falls under the definition above.  Libtool 
shouldn't do that -- at least until gcc/ld get a WHOLE lot smarter (and 
precognitive, too!)

> 
>>With newer gcc's (cygwin version numbers 3.3.3-3, 3.4.1-1, but not
>>3.3.1-3), const variables are placed in an .rdata section.  This causes
>>problems when those variables contain references to OTHER vars that are
>>imported from a dll -- because the runtime relocation machinery can't
>>fixup the address, since the variable holding the address is const --
>>and is in .rdata!
> 
> 
> Yes, I see.  I hope Danny Smith might weigh in here?
> 
> http://sources.redhat.com/ml/binutils/2004-02/msg00003.html

[1] DATA items imported into an app, when the DATA item itself is in the 
DLL's .rdata section, is what is addressed by Danny's binutils patch. 
The problem I'm pointing out is the opposite, and concerns the *pointer* 
that should hold the address of the DLL's DATA item.  That pointer is in 
the application, and is declared const -- and therefore goes into the 
*application's* .rdata section.   Where the runtime-reloc machinery 
can't update it.

--
Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -