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
