How to signal kernel that shared library is not in use by any process anymore ?

[Lior Okman]

On Fri, Dec 21, 2018 at 4:21 PM Lev Olshvang <levonshe at yandex.com> wrote:

>
> Hi All,
>
> I have  an executable (C++) which is the exclusive user of the some shared
> library that it uses only during  the initialization phase.
>
> I would like to free memory used by this shared library, because I am
> running on embedded system.
>
> How can I achieve this?
>
> I know that dlopen() will load shared library, and hope that following
> dlclose() will free this lib memory.
>

According to the dlclose (2) man page:
      "The  function  dlclose() decrements the reference count on the
dynamically loaded shared object referred to by handle.  If the reference
count drops to zero, then the object is unloaded.  All shared
       objects that were automatically loaded when dlopen() was invoked on
the object referred to by handle are recursively closed in the same manner.

       A successful return from dlclose() does not guarantee that the
symbols associated with handle are removed from the caller's address
space.  In addition to references resulting from explicit dlopen()
       calls,  a shared object may have been implicitly loaded (and
reference counted) because of dependencies in other shared objects.  Only
when all references have been released can the shared object be
       removed from the address space."



> 1. Still  I do not know what method should be used to make dynamic linker
> look again into executable and resolve symbols of the newly appeared
> symbols ?
>

If you are using the dlopen/dlclose functions, you are responsible for
symbol resolution for symbols provided by your shared object. After you get
a handle from dlopen(), you need to call dlsym() in order to get a pointer
to your symbol. You can then call that symbol when you need it.


> 2. And  how to tell the dynamic linker ld-linux.so to postpone the symbol
> resolution until dlopen()  will load  the library?
>

When you use dlopen() your compilation shouldn't need to resolve any
symbols from your dlopen()-ed libraries.


> 3. Whether to compile and link executable with this library or leave
> unresolved symbols?
>

You shouldn't have any unresolved symbols, nor should you link to your
library during compilation. I guess the best thing is to show an example:

Given the following library source (printint.c) :

------------------------
#include <stdio.h>

void printint(int num) {
    printf("Called with num=%d \n", num);
}
------------------------

Create a shared object from it using
         gcc -shared -o libprintint.so  printint.c

Now consider the following test program (main.c) which uses printint with
dlopen (removed most of the error handling for clarity here):
-------------------
#include <dlfcn.h>

typedef void printint(int num);

int main(int argc, char *argv[]) {
    void *handle = NULL;
    handle = dlopen("./libprintint.so", RTLD_LAZY);
    if (handle == NULL ) {
        // use dlerror to find out what went wrong
        return -1;
    }
    printint *sym = NULL;
    sym = (printint*)dlsym(handle, "printint");
    if (sym == NULL ) {
        // use dlerror to find out what went wrong
        return -1;
    }
    sym(argc);
    dlclose(handle);
    return 0;
}
--------------

You compile this program like this:

              gcc  main.c -ldl -o a.out

You can verify that the program doesn't dynamically link to libprintint.so
by running "ldd ./a.out". When you run it with libprintit.so in the same
directory it will load the shared library and call the correct function.



> Waiting for your advises,
> Lev.
>
> _______________________________________________
> Linux-il mailing list
> Linux-il at cs.huji.ac.il
> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20181221/7c42a91b/attachment.html>