64bit: cygstdc++-6.dll

[Kai Tietz]

2013/4/14 Corinna Vinschen wrote:
> On Apr 14 11:05, Kai Tietz wrote:
>> 2013/4/14 Corinna Vinschen wrote:
>> > On Apr 13 21:08, Dave Korn wrote:
>> >>   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.
>
> The pseudo-relocator for Cygwin is in the Cygwin DLL itself, and it
> changes the page protection as required for V1 pseudo relocs as well.
>
> Given what you said, that means to me we could drop the .xa ldscript,
> and move the auto import stuff back into the .rdata section where it
> belongs, while keeping auto-import the default.

Right, I would assume so too.

>> [...]
>> 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.
>
> IIUC the 32 bit stuff is not organized in pseudo-GOT entries, so this
> might be a bit tricky to accomplish for 32 bit, unless the affected
> auto-import entries are subsumed under the .rdata_runtime_pseudo_reloc
> section.
>
> As far as the pseudo-GOT entries in the 64 bit code are concerned,
> aren't they in the .rdata_runtime_pseudo_reloc section anyway?

Yes, they are by default in .rdata section.

> We just have to give up the .xa ldscript method.

IMHO yes,  I see no good reason to move them into data, as after
psuedo-relocation they are const, and have to be const.

>> 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.
>
> I don't understand what you mean here.  What exactly is a flaw to have
> for native windows?  Auto-import?

No, IMHO it is a flaw to make const-data and text sections in
pe-coff-image by default writable without good need.  v1 and v2
pseudo-relocation are capable to handle read-only sections.

>
> Corinna

Kai