This is the mail archive of the
mailing list for the Cygwin project.
Re: 64bit: cygstdc++-6.dll
- From: Dave Korn <dave dot korn dot cygwin at gmail dot com>
- To: cygwin-apps at cygwin dot com
- Date: Sat, 13 Apr 2013 21:08:14 +0100
- Subject: Re: 64bit: cygstdc++-6.dll
- References: <5163BE7B dot 3020809 at gmail dot com> <5163EDD0 dot 4040303 at users dot sourceforge dot net> <51643DC1 dot 2070407 at gmail dot com> <5165377D dot 3080208 at users dot sourceforge dot net> <516589ED dot 3090909 at gmail dot com> <20130410161622 dot GC5138 at calimero dot vinschen dot de> <20130411101639 dot GB12461 at calimero dot vinschen dot de> <20130411133759 dot GC18333 at calimero dot vinschen dot de> <20130412155750 dot GG11358 at calimero dot vinschen dot de> <51686F09 dot 4050009 at gmail dot com> <20130413100751 dot GI11358 at calimero dot vinschen dot de>
On 13/04/2013 11:07, Corinna Vinschen wrote:
> On Apr 12 21:31, Dave Korn wrote:
>> Nope, just vague about input and output sections. Enabling auto imports
>> selects a linker script that causes all the .rdata in the input object files
> Out of curiosity, which linker script is that? What's the difference
> to the "normal" one?
Well, since auto import became the default, it is "the normal one", but that
aside, they're both built-in scripts. Compare the output from "ld
--disable-auto-import --verbose" and "ld --verbose" to see the difference. Or
you can look at the copies that ld installs into
/usr/i686-pc-cygwin/lib/ldscripts/; the .x file is the plain one, the .xa is
the auto-import one.
>> to be placed in the plain old .data section of the output executable, so that
>> it will be RW-mapped when loaded. Apparently the Windows runtime loader can't
>> deal with updating import references into RO-mapped pages. The consequence of
>> that is that all the pages with import references get modified and COWed on
>> load and so it reduces the amount of the mapped memory that can be shared
>> between instances of the same executable.
> I'm a bit puzzled in terms of the additional R/W space this amounts to.
> When loading an executable, there is the entire IAT which has to be
> modified by the loader, anyway. That includes all functions and data
> imported from other DLLs. To what extent do the auto-import entries add
> to that? If it's just another indirection, that would add 5 bytes
> (absolute jmp) on i686, and 8 bytes (an absolute address in a pseudo-GOT
> table) on x86_64 per auto-imported symbol. That's not a lot, probably
> not even a 4K page per executable. How significant is that?
But it's not a separate contiguous list of pointers. What's happening is
that there are various structures in the .rdata that contain imported
pointers. They'll be scattered throughout the .rdata, along with all the
other const data that /doesn't/ have pointers that have to be auto-imported.
So depending on the percentages and how it happens to end up in the link
order, it could be any or all of the .rdata pages that get COWed on startup.
>> I'm not sure how significant this is in general usage, and I'm generally in
>> agreement that removing auto-import would be a significant hassle.
> That, too.
Yeah. So I guess we have to live with it.
However it's probably still worth having the markers in libstdc headers,
because that at least makes it possible for people to write applications and
disable auto imports if they're only using libstdc (and/or other shared libs
that also have markers in their headers). That would be desirable for
something that you're going to want to spawn many instances of (either
consecutively or concurrently).