64bit: cygstdc++-6.dll

[Corinna Vinschen]

On Apr 13 21:08, Dave Korn wrote:
> 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.

I'm puzzled.  The .xa file supposedly foldes *all* of .rdata into the
.data section.  So an executable built with --auto-import should have no
.rdata section, right?  And since auto-import is on by default, none of our
binaries should have an .rdata section.  But they have.  I notice that
the 32 bit DLLs don't have a .rdata section, though.  Does that mean
auto-import only influences DLLs?

I also notice that 64 bit binaries and DLLs both have .rdata sections.
But AFAICS, auto-import is enabled for 64 bit, too.

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

Why is that so?  Isn't that, in theory, a problem of gcc not sorting the
data in a way which decouples auto-imported stuff from not-auto-imported
stuff?  Couldn't a gcc fix allow to separate them out into their own
.data_auto_import section which is then folded into .data at link time,
leaving the .rdata stuff alone?

Kai, how much of this is relevant for x86_64?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat