Re: Memory statistics



Behdad Esfahbod a écrit :
On 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?

  
the GOT doesn't have to be paged aligned, but it must be per library because each one of them
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.
***********************************************************************************


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]