cygwin, libtool, dlpreopen, and .rdata

[Charles Wilson]

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/