This is the mail archive of the
cygwin-apps
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: Fri, 12 Apr 2013 21:31:05 +0100
- Subject: Re: 64bit: cygstdc++-6.dll
- References: <514EBA42 dot 7010701 at users dot sourceforge dot net> <20130325085219 dot GF2387 at calimero dot vinschen dot de> <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>
On 12/04/2013 16:57, Corinna Vinschen wrote:
> Dave? Ping?
Heh, don't panic, I'm still here! Just needed some sleep :)
> On Apr 11 15:37, Corinna Vinschen wrote:
>> On Apr 11 12:16, Corinna Vinschen wrote:
>>> On Apr 10 18:16, Corinna Vinschen wrote:
>>>> On Apr 10 16:49, Dave Korn wrote:
>>>>> On 10/04/2013 10:57, Yaakov (Cygwin/X) wrote:
>>>>>
>>>>>> Could you explain the necessity of the dllimport's in the same patch?
>>>>> The idea is to one day be able to move away from having auto-import enabled
>>>>> by default in binutils, so that .rdata can go back into the read-only-mapped
>>>>> .rdata section and be shared between processes as it ought.
>>>> Doesn't that affect applications which use something like
>>>>
>>>> extern int optind;
>>>>
>>>> in their code? Kai did quite a job to get this working on x86_64 by
>>>> implementing the medium/large code models for x86_64, and Cygwin's
>>>> x86_64 gcc uses the medium code model by default. Disabling this again
>>>> would be rather counterproductive.
>>> What about this issue? If the idea is to revert all automatism which
>>> allows to declare external variables in DLL s without dllimport, then
>>> I don't think that's a good idea for Cygwin.
>>>
>>> If I misunderstand the issue, please say so.
>> Oh, and, btw., I don't quite understand
>>
>> "so that .rdata can go back into the read-only-mapped .rdata section"
>>
>> Typo?
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
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 not sure how significant this is in general usage, and I'm generally in
agreement that removing auto-import would be a significant hassle.
I think it might explain why, when I'm running the GCC testsuite and have
been through a few tens of thousands of compiles, I frequently see a whole
bunch of gcc.exe instances just sitting there, doing nothing and using almost
no CPU for 20 to 30 seconds while their stack traces indicate they're stuck in
kernel paging-and-caching-related code.
But overall, I guess we have to live with it.
cheers,
DaveK