Home > Archive > Unix Programming > January 2005 > Reverse of dlsym(3)?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Reverse of dlsym(3)?
|
|
| Michael B Allen 2005-01-06, 8:57 am |
| 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
| |
| Kornilios Kourtis 2005-01-06, 8:57 am |
| 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[color=darkred]
>
> 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)
| |
| Michael B Allen 2005-01-08, 3:57 am |
| 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
| |
| Casper H.S. Dik 2005-01-08, 8:56 am |
| 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.
| |
| Thomas Dickey 2005-01-08, 8:56 am |
| Casper H.S. Dik <Casper.Dik@sun.com> wrote:
> Kornilios Kourtis <kkourt@NO.cslab.MORE.ece.SPAM.ntua.gr> writes:
[color=darkred]
> 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
| |
| Casper H.S. Dik 2005-01-08, 3:57 pm |
| Thomas Dickey <dickey@saltmine.radix.net> writes:
>Casper H.S. Dik <Casper.Dik@sun.com> wrote:
[color=darkred]
[color=darkred]
[color=darkred]
>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
| |
| Thomas Dickey 2005-01-08, 3:57 pm |
| 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
| |
| Kenny McCormack 2005-01-08, 3:57 pm |
| 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).
| |
| Casper H.S. Dik 2005-01-08, 8:57 pm |
| gazelle@yin.interaccess.com (Kenny McCormack) writes:
>In article <41dfb86b$0$6203$e4fe514c@news.xs4all.nl>,
>Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:
[color=darkred]
>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).
Judging by the manual page, "GNU_EXTENSION" just means "not in
any standard we could find". Something we use __EXTENSION__ for, I
think.
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.
| |
| Kornilios Kourtis 2005-01-20, 8:57 am |
|
Kornilios Kourtis <kkourt@NO.cslab.MORE.ece.SPAM.ntua.gr> writes:
Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:[color=darkred]
gazelle@yin.interaccess.com (Kenny McCormack) writes:[color=darkred]
Casper H.S. Dik <Casper.Dik@Sun.COM> wrote:[color=darkred]
> Judging by the manual page, "GNU_EXTENSION" just means "not in
> any standard we could find". Something we use __EXTENSION__ for, I
> think.
Just for the record I used the phrase "GNU extension" as in "not defined
by POSIX" or "don't now if other systems support it".
Thanks for the clarification.
--
Kornilios Kourtis
Computers are useless. They can only give you answers.
- Pablo Picasso
|
|
|
|
|