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
