list symbols provided by a shared library at runtime

[Vittorio A.]

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

[John Reiser]

> 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

--

[Vittorio A.]

On Sep 14, 1:37 pm, John Reiser <jrei...@BitWagon.com> 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

[Paul Pluzhnikov]

"Vittorio A." <news_a...@ymail.com> 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.

[rsaga...@ulmapackaging.com]

On 14 sep, 18:02, Paul Pluzhnikov <ppluzhnikov-...@gmail.com> wrote:

> "Vittorio A." <news_acco...@ymail.com> 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

[Nate Eldredge]

rsaga...@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?

[rsaga...@ulmapackaging.com]

On 23 oct, 20:06, Nate Eldredge <n...@vulcan.lan> wrote:
> rsagarz...@ulmapackaging.com writes:
> > Is it also possible to readsymbolsinside data structures? On the

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".