Global data loaded if symbols aren't resolved

Andrew Haley aph@redhat.com
Mon Aug 17 20:49:00 GMT 2009


Marcus Clyne wrote:
> Ian Lance Taylor wrote:
>> Marcus Clyne <maccaday@gmail.com> writes:
>>
>>  
>>>>> If a shared object is loaded using dlopen etc and the symbols in its
>>>>> object aren't used (specifically they are defined elsewhere already
>>>>> inside that process), is the data in the symbols automatically loaded
>>>>> into memory or is it skipped (assuming there are no other programs
>>>>> using those symbols on the system) and the memory available for other
>>>>> purposes?
>>>>>             
>>>> If you open a shared library with dlopen, then that library is loaded
>>>> into memory.  This will use up virtual address space.  If you don't use
>>>> the library for anything, then the pages will never be loaded into RAM.
>>>>         
>>> When the object loaded initially with dlopen(), is there anything
>>> that's transferred to RAM (e.g. the page where the symbol names are),
>>> or are they only copied to the swap space directly?  If that's the
>>> case, are they then loaded into RAM when dlsym() is called?
>>>     
>>
>> Most of a shared library is read-only and shared.  Those pages are
>> simply mapped into your virtual address space--no copying occurs.  In a
>> typical shared library, a few pages must be modified by the dynamic
>> linker when the library is loaded: those pages will be copied into RAM
>> and modified, and if not referenced will eventually be swapped out.
>>
>>   
> Would pages that used symbols from other libraries be included in the
> pages that are copied and modified?  If that's the case, what about
> pages that have calls to symbols in the standard c library.  Are they
> also copied/modified?  What about global variables inside the shared
> object?  Presumably they are copied, no?

You're asking a lot of questions here!

Code in a shared library is PIC, so its pages are not writable and
all fixups go via the GOT or the PLT.  Hint: type "GOT PLT" into
Google and all will become clear.

Andrew.



More information about the Gcc-help mailing list