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