Re: 64bit: cygstdc++-6.dll

[Kai Tietz <ktietz70 at googlemail dot com>]

2013/4/14 Corinna Vinschen wrote:
> 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?

AFAICS it isn't relevant for x64.  I even doubt it is at all relevant
for 32-bit, too.  The reason I know about why gcc put relocated const
data into the .data section (and not as it should be into the .rdata
one) was caused by old pseudo-relocation-code.  It wasn't able to
modify page-priviledges and therefore data has to be moved into .data
(and even worse code-section was made writable by linker).  We more
modern pseudo-reloc code I doubt that this is still necessary.

I am not sure where this information comes from, but by my research I
can't find documentation that pe-loader wouldn't be able to do
importing into tobe-remapped pages in an efficient way.  I did some
tests and it works flaw-less.  Also by information I got from "Windows
Internals" book, I see that importing and relocation is done on
none-access-limitted pages, which are later-on restricted by pe-loader
to their desired access specified in PE's section-table.  But well, I
might misunderstood here the reasoning.

Also the argumentation about none-autoimporting enabled links puzzles
me, too.  If no auto-import happens there is no need to do
page-access-remappings done by gcc or ld.  As nobody writes actual to
these pages from POV of pe-loader.  Cygwin might want to optimize the
amount of pages needing remapping by sorting pseudo-GOT-entries in
image together, but that is for sure a different story as to move
things from rdata into data, or making code-section writable.

If cygwin needs that behavior in gcc (and binutils), then do this
please in cygwin-specific way there.  It is in general a flaw to have
this also for native windows targets enabled.



>
> Corinna

Kai