Can anyone give me a pointer about shared sections in a DLL?
I have a rather old book (published circa 1998) saying that .text section is shared, which I suppose the raison d'atre of DLL. But I could not find any info about .rdata section. I presume that .rdata section is shared, but there is no way to verify it on my part.

I tried adding SHARED attribute in .def file, but linker warned me that .rdata contained relocation data so that forcing SHARED attribute would result in incorrect behavior. Then, I tried the same thing on .text section, and linker issued me the same warning.
Now I wonder what is the truth.

<edit>
What I am asking is: are .text and .rdata really shared in the memory? If so, how do I verify that?
I'm not asking linker flags or .def lines.
</edit>
Posted on 2004-03-17 18:37:19 by Starless
Afaik, setting the SHARED linker flag means the section will be shared as-is in memory - all instances accessing the section will get exactly that section, no copy-on-write etc.

By default, all sections should be 'shared' by multiple processes, automatically. However, this is not the "verbatim" sharing, writing will trigger Copy-On-Write, and will give a copy of the affected pages in the process doing the writes. This scheme obviously works very well for code and resource data, which is almost exclusively read-only. It can also give gains for data when there's large parts of read-only data (large blocks of read/write data tend to be stack or heap anyway).

If you want to verify the sharing, you'd probably have to look at linear->physical mappings in a couple of processes :)
Posted on 2004-03-18 05:47:09 by f0dder
Although I guess what copy-on-write would mean, I don't know its technical details. Do you have any pointer for that?

Your post appears to allude that .text is not shared 'verbatim'. Now that .rdata usually contains IAT, .rdata may not be shared either, following your explanation. If that is what you mean, it is consistent with the linker warnings I got. Obviously, I can work around by creating another data segment with 'shared' attribute.

Then, the question is, what is the use of DLL, when it does not share .text? I wish there is MS employee and/or engineer here to explain it...
Posted on 2004-03-18 19:54:29 by Starless
Copy-On-Write means that the sections are mapped with read-only pages, no matter what the PE header says. On a page-fault, the #PF handler checks whether the page is in a writable PE section. If it is, a copy of the physical page is made, and the page-table entry for the process is updated to point to this copy instead of the 'pure' page.

Verbatim sharing would obviously be no good for regular code and data sections, as modifications done in one process would affect all other instances.


what is the use of DLL, when it does not share .text?

It does share both code and data. Unless copy-on-write happens (and this can of course only happen in writable sections, read-only causes a normal "illegal action" pagefault), physical memory will only be allocated once for the pages.

/section:blah,shared means that the section will be mapped directly in all instances, without COW - changes done in one process will affect all other running instances of that program.
Posted on 2004-03-19 07:26:58 by f0dder

Then, the question is, what is the use of DLL, when it does not share .text?
The .text section can be shared when it is loaded with no relocation. If the .text section must be relocated (because of address clashes), a relocated version will be created, and the new version won't be shared.

The purpose of a DLL is the same as the purpose of static libraries -- to provide the primary copy of code, usually as a set of subroutines, that will be combined with other code. A DLL may also hold other sharable resources, such as icons and bitmaps. Because it is a separate file, you won't have multiple copies of the library embedded in several EXEs (or other DLLs).
Posted on 2004-03-19 23:58:14 by tenkey

The .text section can be shared when it is loaded with no relocation. If the .text section must be relocated (because of address clashes), a relocated version will be created, and the new version won't be shared.

This will never happen with EXEs, but is a good reason why you should choose proper bases (perhaps using the SDK rebase tool) for your DLLs :)
Posted on 2004-03-20 04:12:20 by f0dder