list symbols provided by a shared library at runtime - Linux

This is a discussion on list symbols provided by a shared library at runtime - Linux ; Hello, I would like to get a complete list of symbols that are available from a specific library after the 'handle=dlopen("libmylib.so",RTLD_LAZY)' call. Using dlsym(...) I can query the existence of known symbol names, but how do I get a complete ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: list symbols provided by a shared library at runtime

  1. list symbols provided by a shared library at runtime

    Hello, I would like to get a complete list of symbols that are
    available from a specific library after the
    'handle=dlopen("libmylib.so",RTLD_LAZY)' call.
    Using dlsym(...) I can query the existence of known symbol names, but
    how do I get a complete list (like the output of 'nm libmylib.so' but
    without using th 'nm' system call)?

    Thanks
    Vittorio

  2. Re: list symbols provided by a shared library at runtime

    > Hello, I would like to get a complete list of symbols that are
    > available from a specific library after the
    > 'handle=dlopen("libmylib.so",RTLD_LAZY)' call.


    Look at /usr/include/elf.h, then consult the source code for:
    readelf --headers --dynamic --symbols libmylib.so

    --

  3. Re: list symbols provided by a shared library at runtime

    On Sep 14, 1:37 pm, John Reiser wrote:

    > Look at /usr/include/elf.h, then consult the source code for:
    > readelf --headers --dynamic --symbols libmylib.so
    >


    Thanks for pointing me to the source which I can use as a workaround.
    This will help a lot, if I really have to read the library file and
    parse the ELF structure to find the symbols.

    But I would like to avoid opening the library file a second time,
    after dlopen() has already read it. Mainly, because I'm laz^W I want
    to work efficiently without duplicating information that dlopen
    probably has acquired already. Secondly because of possible
    performance issues.

    So, is there definitely no function available which has access to the
    information which dlsym() needs to find symbols, and which returns all
    of these symbols? Or does dlsym() also read the library again and
    again for each symbol which I request? Then it's understandable that
    no list of all defined symbols is kept in memory.

    Thanks
    Vittorio

  4. Re: list symbols provided by a shared library at runtime

    "Vittorio A." writes:

    > Thanks for pointing me to the source which I can use as a workaround.
    > This will help a lot, if I really have to read the library file and
    > parse the ELF structure to find the symbols.


    AFAIK, there is no glibc function that iterates over all
    symbols. You'll have to roll your own, or use one written by someone
    else (look for libelf library).

    > But I would like to avoid opening the library file a second time,
    > after dlopen() has already read it.


    The handle returned by dlopen() on Linux is actually a pointer to
    'struct link_map', and ((struct link_map *)h)->l_addr points to
    the in-memory Elf{32,64}_Ehdr (for non-prelinked shared libraries).

    So you *can* get all the info you need without reopening the library
    on disk.

    An even better alternative (which also works with prelinked
    libraries), is to use dl_iterate_phdr().

    > Mainly, because I'm laz^W I want
    > to work efficiently without duplicating information that dlopen
    > probably has acquired already. Secondly because of possible
    > performance issues.


    The "cost" of dlopen()ing a library is significantly greater than
    the cost of a single open(). Optimizing that "open" out is likely
    a case of premature optimization.

    > So, is there definitely no function available which has access to the
    > information which dlsym() needs to find symbols, and which returns all
    > of these symbols?


    Available where? In glibc: no. In libelf: yes.

    > Or does dlsym() also read the library again and
    > again for each symbol which I request?


    It doesn't do that: ELF images contain a hash table of symbols,
    which allows dlsym() to efficiently find a given symbol without
    ever constructing a complete list of the available ones.

    You can see how dlsym() works as well: look in
    glibc-X.Y.Z/elf/dl-lookup.c and do-lookup.h

    Cheers,
    --
    In order to understand recursion you must first understand recursion.
    Remove /-nsp/ for email.

  5. Re: list symbols provided by a shared library at runtime

    On 14 sep, 18:02, Paul Pluzhnikov wrote:
    > "Vittorio A." writes:
    > > Thanks for pointing me to the source which I can use as a workaround.
    > > This will help a lot, if I really have to read the library file and
    > > parse the ELF structure to find thesymbols.

    >
    > AFAIK, there is no glibc function that iterates over allsymbols. You'll have to roll your own, or use one written by someone
    > else (look for libelf library).
    >
    > > But I would like to avoid opening the library file a second time,
    > > after dlopen() has already read it.

    >
    > The handle returned by dlopen() on Linux is actually a pointer to
    > 'struct link_map', and ((struct link_map *)h)->l_addr points to
    > the in-memory Elf{32,64}_Ehdr (for non-prelinked shared libraries).
    >
    > So you *can* get all the info you need without reopening the library
    > on disk.
    >
    > An even better alternative (which also works with prelinked
    > libraries), is to use dl_iterate_phdr().
    >
    > > Mainly, because I'm laz^W *I want
    > > to work efficiently without duplicating information that dlopen
    > > probably has acquired already. Secondly because of possible
    > > performance issues.

    >
    > The "cost" of dlopen()ing a library is significantly greater than
    > the cost of a single open(). Optimizing that "open" out is likely
    > a case of premature optimization.
    >
    > > So, is there definitely no function available which has access to the
    > > information which dlsym() needs to findsymbols, and which returns all
    > > of thesesymbols?

    >
    > Available where? In glibc: no. In libelf: yes.
    >
    > > Or does dlsym() also read the library again and
    > > again for each symbol which I request?

    >
    > It doesn't do that: ELF images contain a hash table ofsymbols,
    > which allows dlsym() to efficiently find a given symbol without
    > ever constructing a completelistof the available ones.
    >
    > You can see how dlsym() works as well: look in
    > glibc-X.Y.Z/elf/dl-lookup.c and do-lookup.h
    >
    > Cheers,
    > --
    > In order to understand recursion you must first understand recursion.
    > Remove /-nsp/ for email.


    Is it also possible to read symbols inside data structures? On the
    symbol table it appears just the name and the size of a variable but,
    is it possible to get the different variable's elements from a ELF
    file?

    Thankyou,

    Raimundo Sagarzazu

  6. Re: list symbols provided by a shared library at runtime

    rsagarzazu@ulmapackaging.com writes:

    > Is it also possible to read symbols inside data structures? On the
    > symbol table it appears just the name and the size of a variable but,
    > is it possible to get the different variable's elements from a ELF
    > file?


    So you're thinking, if a shared library has

    struct foo { int a; double b; } argh;

    you'd like to not only know the address and size of argh, but also to
    find out about the existence of argh.a and argh.b.

    AFAIK, this information is not even present in the object file. Type
    information is needed by the compiler, not the linker. Normally this
    would be communicated by a header file.

    It might be present in the debugging information, if the library was
    compiled with -g and not stripped, but that rarely happens. It would
    probably be challenging to get at this information even if it was
    present, since AFAIK the format for debug info is complicated and not
    understood by many people.

    What are you trying to accomplish with all this?

  7. Re: list symbols provided by a shared library at runtime

    On 23 oct, 20:06, Nate Eldredge wrote:
    > rsagarz...@ulmapackaging.com writes:
    > > Is it also possible to readsymbolsinside data structures? On the
    > > symbol table it appears just the name and the size of a variable but,
    > > is it possible to get the different variable's elements from aELF
    > > file?

    >
    > So you're thinking, if a shared library has
    >
    > struct foo { int a; double b; } argh;
    >
    > you'd like to not only know the address and size of argh, but also to
    > find out about the existence of argh.a and argh.b.
    >
    > AFAIK, this information is not even present in the object file. *Type
    > information is needed by the compiler, not the linker. *Normally this
    > would be communicated by a header file.
    >
    > It might be present in the debugging information, if the library was
    > compiled with -g and not stripped, but that rarely happens. *It would
    > probably be challenging to get at this information even if it was
    > present, since AFAIK the format for debug info is complicated and not
    > understood by many people.
    >
    > What are you trying to accomplish with all this?


    Thankyou for your answer. I'm going to focus on the compiler.

    What I'm trying is to have a kind of extenal "scope" of the global
    variables of an application. One thread of this "target" application
    would show (send) the values of the global variables but I'm trying to
    have an image of all global variables present on it in order to choose
    some of them from this "external scope".


+ Reply to Thread