This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: 64bit: cygstdc++-6.dll
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-apps at cygwin dot com
- Date: Sat, 13 Apr 2013 12:07:51 +0200
- 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>
- Reply-to: cygwin-apps at cygwin dot com
On Apr 12 21:31, Dave Korn wrote:
> On 12/04/2013 16:57, Corinna Vinschen wrote:
> >>>> On Apr 10 16:49, Dave Korn wrote:
> >>>>> 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
Out of curiosity, which linker script is that? What's the difference
to the "normal" 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?
> 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.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat