Behdad Esfahbod a écrit :
the GOT doesn't have to be paged aligned, but it must be per library because each one of themOn Tue, 25 Apr 2006, Federico Mena Quintero wrote:But yeah, even if we get down to 4 KB per library, it still becomes a big number when you consider 4 KB * num_libraries * num_processes.AFAIU, other than prelinking, there's no reason that the GOT tables have to be page-aligned and per library. Or is it? must be located at a fixed offset from the code in memory. This offset is chosen at link time, when generating the shared library itself. For example, within the page just below the code's lowest address, as in: +----------------+ | | | | | | | Shared | | Library | | .text | +----------------+ | | | .got | +----------------+ You cannot move the .got after the shared library has been created, because the .text doesn't contain *any* relocation (the whole purpose of PIC), just IP-based constant offsets to .got entries, like in the following fictional example: call __i686.get_pc_thunk.bx # special function added by the linker, retrieve IP in ebx. add $0x527a4,%ebx # compute .got table address in ebx mov 4(%ebx),%eax # read .got[4] in eax, let's say it's the address of the library's .data mov 0x12, 564(%eax) # write value 18 to a global variable at .data[564] the function "__i686.get_pc_thunk.bx" is added automatically to ".text" by the linker, and the call is IP-relative anyway, so no relocation is needed for it. the magic constant $0x527a4 is computed by the linker when creating the shared library. It does so by removing any relocations in PIC object code that are related to the .got and converting them into offsets. That's normally the only relocations the compiler is allowed to generate for .text (along those for .plt I guess) the value of .got[4] is set at load time by the dynamic-linker and points to the .data of the shared library, if any. This one doesn't (generally) need to be page-aligned. Notice that offset 4 here is completely fictional. Because the .got position is fixed regarding the .text of each library, it's not practical to group the .gots of several libraries into a single writable page. That would require to know in advance the loading address of each library involved in the group, or create vast gaps in the virtual address space used to load the libs otherwise. However, you can create a single shared library that groups the code corresponding to the PIC code of several libraries, and will be able to share pages to store the corresponding .gots. Given that Unix uses symbolic links to point to libraries, it should be possible to do so without changing the clients, as long as they stick to linking to 'libfoo.so.major', which can be a link to 'libfoobarzoo.so.whatever' (just like libbar.so.n and libzoo.so.n) I don't have any numbers to show, but it might be worthwhile for certain libs, and not terribly difficult to implement. However, I'm not sure that the savings would be important. - David *********************************************************************************** Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the postmaster nds com and destroy the original message. *********************************************************************************** |