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
