This is the mail archive of the cygwin-apps 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: 64bit: cygstdc++-6.dll

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


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