Reverse of dlsym(3)?

Is there a way to resolve an address to a symbol name? Meaning the
reverse of dlsym(3).

I can think of one way to do it. I could preload a table of symbol
address and corresponding function names like:

typedef struct {
void *sym;
char *nam;
} symbol_names[] = {
fn0, "fn0",
fn1, "fn1",
global0, "global0"
};

and just search the table for the function names.

Any better ideas?

Thanks,
Mike

Michael B Allen <mba2000@ioplex.com> wrote:
> Is there a way to resolve an address to a symbol name? Meaning the
> reverse of dlsym(3).
>
> I can think of one way to do it. I could preload a table of symbol
> address and corresponding function names like:
>
>    typedef struct {
>        void *sym;
>        char *nam;
>    } symbol_names[] = {
>        fn0, "fn0",
>        fn1, "fn1",
>        global0, "global0"
>    };
>
> and just search the table for the function names.
>
> Any better ideas?
>
> Thanks,
> Mike

there is dladdr(3) but it's a GNU extension and I don't know what
kind of system you are using.

from dladdr(3):

#define GNU_SOURCE
#include <dlfcn.h>

int dladdr(void *addr, Dl_info *info);

The function dladdr() takes a function pointer  and  tries  to  resolve
name and file where it is located. Information is stored in the Dl_info
structure:

typedef struct {
const char *dli_fname;/* File name of defining object */
void *dli_fbase;      /* Load address of that object */
const char *dli_sname;/* Name of nearest lower symbol */
void *dli_dr;      /* Exact value of nearest symbol */
} Dl_info;



--
Kornilios Kourtis

Computers are useless. They can only give you answers.
- Pablo Picasso

Kornilios Kourtis wrote:
> Michael B Allen <mba2000@ioplex.com> wrote: 
>
> there is dladdr(3) but it's a GNU extension and I don't know what
> kind of system you are using.
>

dladdr(3), with support for the dli_fname member, seems to be available
for a fair amount of UNIX(-like) systems.  I know for sure about AIX,
Solaris and Linux, and doing a little googling HP/UX, MacOS/X and ?BSD
seem to support it as well.

(Sorry if this post appears multiple times, but (beta) google groups is
fooling around with me)

chris wrote:
> Kornilios Kourtis wrote: 
the 
>
> dladdr(3), with support for the dli_fname member, seems to be
available

Ups!  Of course dli_sname would be the relevant member for the symbol,
but
nevertheless it should be available along with the dli_fname one.

> for a fair amount of UNIX(-like) systems.  I know for sure about AIX,
> Solaris and Linux, and doing a little googling HP/UX, MacOS/X and
?BSD
> seem to support it as well.
>
> (Sorry if this post appears multiple times, but (beta) google groups
is
> fooling around with me)

On Thu, 06 Jan 2005 07:38:48 -0500, Kornilios Kourtis wrote:

> Michael B Allen <mba2000@ioplex.com> wrote: 
>
> there is dladdr(3) but it's a GNU extension and I don't know what kind
> of system you are using.
>
> from dladdr(3):
>
>        #define GNU_SOURCE
>        #include <dlfcn.h>
>
>        int dladdr(void *addr, Dl_info *info);
>
>        The function dladdr() takes a function pointer  and  tries  to
>        resolve name and file where it is located. Information is stored
>        in the Dl_info structure:
>
>        typedef struct {
>          const char *dli_fname;/* File name of defining object */ void
>          *dli_fbase;      /* Load address of that object */ const char
>          *dli_sname;/* Name of nearest lower symbol */ void *dli_dr;
>              /* Exact value of nearest symbol */
>        } Dl_info;

Thanks. This does appear to be what I'm looking for. However once I
actually started using it I noticed a problem. If the code containing
the symbol was loaded using dlopen(sopath, RTLD_NOW | RTLD_GLOBAL)
it cannot resolve it. I get traces like the following where I believe
module_load is calling the module specific 'modinit' function.

:0x41149762: 708
:0x4114711b
libbase.so.0.3:module_load
libbase.so.0.3:module_load_all

and

libmba.so.0.8:allocator_alloc: 4096
libmba.so.0.8:pool_get
:0x4114954f
:0x411451d3

This is the real problem. The bulk of my code is in the modules so I
can see where the calls are coming from and that is the whole point of
this exercise.

Does anyone have a sophisticated enough understanding of how libdl works
to tell me what's going wrong (and maybe how to fix it)?

Thanks,
Mike

Kornilios Kourtis <kkourt@NO.cslab.MORE.ece.SPAM.ntua.gr> writes:

>there is dladdr(3) but it's a GNU extension and I don't know what
>kind of system you are using.

It's not a GNU extension; it's from Solaris.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Casper H.S. Dik <Casper.Dik@sun.com> wrote:
> Kornilios Kourtis <kkourt@NO.cslab.MORE.ece.SPAM.ntua.gr> writes:
 

> It's not a GNU extension; it's from Solaris.

It would be useful to give more information (date of introduction,
places where it has been imitated, etc).

The first hits google finds for "dladdr" are for HPUX and AIX, and they
don't mention Solaris on those pages.

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Thomas Dickey <dickey@saltmine.radix.net> writes:

>Casper H.S. Dik <Casper.Dik@sun.com> wrote: 
 
 

>It would be useful to give more information (date of introduction,
>places where it has been imitated, etc).

Unfortunately, we generally do not record such information in
our manual pages; since Solaris 2.6, we do have some form of record
in the libraries.

As far as I can tell the code was added to Solaris in 1993;
this appears to conincide with Solaris 2.4 (I have some old source
code which says:

requires Solaris 2.4 or later for pretty addresses (for dladdr())

>The first hits google finds for "dladdr" are for HPUX and AIX, and they
>don't mention Solaris on those pages.

I don't think any of the commercial Unixes has a policy of adding
references to the origin of functions to manual pages.

One of the first hits:

http://www.gsp.com/cgi-bin/man.cgi?...=3&topic=dladdr

mentions:


HISTORY

The dladdr function first appeared in the Solaris operating system.


Our internal architecture review documentation of this feature dates
from Oct 1993 and makes no mention of copying the interface from
some place; that makes it extremely unlikely it was copied from outside
sources.

Solaris 2.4 was officially released in July or so of 1994.

It's been imitated all over the map since, apparently, including
some implementations which return more information.

Casper

Casper H.S. Dik <Casper.Dik@sun.com> wrote:

> Our internal architecture review documentation of this feature dates
> from Oct 1993 and makes no mention of copying the interface from
> some place; that makes it extremely unlikely it was copied from outside
> sources.

> Solaris 2.4 was officially released in July or so of 1994.

thanks for the update

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

In article <41dfb86b$0$6203$e4fe514c@news.xs4all.nl>,
Casper H.S. Dik  <Casper.Dik@Sun.COM> wrote:
>Kornilios Kourtis <kkourt@NO.cslab.MORE.ece.SPAM.ntua.gr> writes:
> 
>
>It's not a GNU extension; it's from Solaris.

Yes, interestingly enough, I cannot find it on my recent (1 yr old, kernel
2.4.22) Linux system, but I do find it on my old (Solaris 2.5) Sun system(s)
.