This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygwin, libtool, dlpreopen, and .rdata

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?

[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.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]