Hi,
On Fri, 15 Sep 2006 13:01:47 +0900
mpsuzuki@xxxxxxxxxxxxxxxxx wrote:
>If the functions to be checked is in yet-not-loaded pluggable
>modules (e.g. pango-arabic-fc.so), g_module_symbol() will be
>useful.
>
>But, ellipsis issue is slightly different, because it is in
>libpango, and it is linked at once when the program is started.
>It's out of gmodule framework, so we don't have module object
>for libpango, as a result, g_module_symbol() cannot scan the
>symbols in libpango - I suppose.
THIS WAS MISTAKE.
During a test on GNU/Linux, I found g_module_symbol() can
scan the symbols that are already resolved (before calling
any g_module_open()), in some systems.
--
On HP-UX, g_module_open() is a wrapper of shl_findsym().
According to the "man shl_findsym":
...If a pointer to NULL is passed for this argument,
shl_findsym() searches all user defined symbols (those defined by
shl_definesym()), all currently loaded shared libraries and the
program to find the symbol; otherwise shl_findsym() searches only
the specified shared library. The return value of handle will be
NULL if the symbol found was generated via shl_definesym().
Otherwise the handle of the library where the symbol was found is
returned. The special handle PROG_HANDLE can be used to refer to
the program itself, so that symbols exported from the program can
also be accessed dynamically.
So, we can scan libpango symbols (without g_module_open())
by passing PROG_HANDLE (or NULL?) to g_module_open().
--
On MacOS X, g_module_open() is a wrapper of NSLookupSymbolInModule().
static gpointer
_g_module_symbol (gpointer handle,
const gchar *symbol_name)
{
NSSymbol sym;
char *msg;
if (handle == &self_module)
{
if (NSIsSymbolNameDefined (symbol_name))
sym = NSLookupAndBindSymbol (symbol_name);
else
sym = NULL;
}
else
sym = NSLookupSymbolInModule (handle, symbol_name);
...
As you can see, if we can pass "&self_module" to g_module_symbol,
we can scan libpango symbols without g_module_open(). However,
yet I don't know how to calculate &self_module.
--
I don't have conclusion for platforms with Sun-style dynamic
loaders (dlopen(),dlsym(),dlclose()), and AIX. On these systems,
gmodule just pass arguments to dlsym(), aslike:
static gpointer
_g_module_symbol (gpointer handle,
const gchar *symbol_name)
{
gpointer p;
p = dlsym (handle, symbol_name);
if (!p)
g_module_set_error (fetch_dlerror (FALSE));
return p;
}
According to FreeBSD 4.11's "man dlsym", passing NULL handle
is enough to scan symbols before dlopen().
If dlsym() is called with the special handle NULL,
it is interpreted as a reference to the executable
or shared object from which the call is being made.
Thus a shared object can reference its own symbols.
I can find similar notes in SunOS 4.1.4 "man dlsym".
--
GNU/Linux "man dlsym" is obsolete, does not mention about
the case when we pass NULL handle, but when I do small
experiments, passing NULL handle works. I tested on
glibc-2.0.7pre and glibc-2.2.5.
--
AIX 5.3 (at least) has special handle to scan the symbol
of the running process: RTLD_MYSELF.
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.basetechref/doc/basetrf1/dlsym.htm?resultof=%22%64%6c%73%79%6d%22%20
AIX 5.1 doesn't mention.
http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/basetrf1/dlsym.htm#HDRDUP0003
--
At present, I have no access to other systems. However,
I can say, gmodules does not provide portable method
to scan the symbols of the symbols without g_module_open().
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
