64bit: cygstdc++-6.dll

[Corinna Vinschen]

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