Re: dlsym() on implicit loaded symbols
On Sun, Jul 16, 2006 at 03:26:33PM +0200, Roland Dittel wrote:
Am 16.07.2006 um 14:33 schrieb Simon 'corecode' Schubert:
Roland Dittel wrote:
We have a issue with dlsym() on symbols imported by a library that
was loaded with dlopen(). Our code loads the libssl with dlopen()
and then do a dlsym() on several symbols. This works for all
symbols exported by libssl itself but fails for symbols exported by
libcrypto.
[..]
func = dlsym(handle, CRYPTO_set_id_callback);
you have to use RTLD_DEFAULT instead of handle, but I agree, this is
not in conformance with SUSv3:
That's it. Thank you very much.
Roland
The dlsym() function shall search for the named symbol in all
objects loaded automatically as a result of loading the object
referenced by handle (see dlopen()). Load ordering is used in dlsym()
operations upon the global symbol object. The symbol resolution
algorithm used shall be dependency order as described in dlopen().
The RTLD_DEFAULT and RTLD_NEXT flags are reserved for future use.
Note in all objects loaded automatically. Good catch!
Try this (against RELENG_6), patch for CURRENT needs some editing.
Index: rtld.c
===
RCS file: /usr/local/arch/ncvs/src/libexec/rtld-elf/rtld.c,v
retrieving revision 1.106.2.2
diff -u -r1.106.2.2 rtld.c
--- rtld.c 30 Dec 2005 22:13:56 - 1.106.2.2
+++ rtld.c 16 Jul 2006 18:05:39 -
@@ -123,7 +123,7 @@
static const Elf_Sym *symlook_default(const char *, unsigned long hash,
const Obj_Entry *refobj, const Obj_Entry **defobj_out, bool in_plt);
static const Elf_Sym *symlook_list(const char *, unsigned long,
- Objlist *, const Obj_Entry **, bool in_plt, DoneList *);
+ const Objlist *, const Obj_Entry **, bool in_plt, DoneList *);
static void trace_loaded_objects(Obj_Entry *obj);
static void unlink_object(Obj_Entry *);
static void unload_object(Obj_Entry *);
@@ -1805,25 +1805,22 @@
def = symlook_default(name, hash, obj, defobj, true);
}
} else {
+DoneList donelist;
+
if ((obj = dlcheck(handle)) == NULL) {
rlock_release(rtld_bind_lock, lockstate);
return NULL;
}
+ donelist_init(donelist);
if (obj-mainprog) {
- DoneList donelist;
/* Search main program and all libraries loaded by it. */
- donelist_init(donelist);
def = symlook_list(name, hash, list_main, defobj, true,
donelist);
} else {
- /*
-* XXX - This isn't correct. The search should include the whole
-* DAG rooted at the given object.
-*/
- def = symlook_obj(name, hash, obj, true);
- defobj = obj;
+ def = symlook_list(name, hash, (obj-dagmembers), defobj, true,
+ donelist);
}
}
@@ -2274,7 +2271,7 @@
}
static const Elf_Sym *
-symlook_list(const char *name, unsigned long hash, Objlist *objlist,
+symlook_list(const char *name, unsigned long hash, const Objlist *objlist,
const Obj_Entry **defobj_out, bool in_plt, DoneList *dlp)
{
const Elf_Sym *symp;
pgpmppDFtcE3r.pgp
Description: PGP signature
Re: dlsym() on implicit loaded symbols
Simon 'corecode' Schubert wrote: Roland Dittel wrote: Hi all, We have a issue with dlsym() on symbols imported by a library that was loaded with dlopen(). Our code loads the libssl with dlopen() and then do a dlsym() on several symbols. This works for all symbols exported by libssl itself but fails for symbols exported by libcrypto. Libssl is dynamically linked to libcrypto and should be loaded for libssl. I did a truss and the FreeBSD loader loads libcrypto but does not read anything from the file pointer. could you post a sample code fragment which illustrates the problem you are seeing? Sure, attached is a simple example that tries to load the symbol CRYPTO_set_id_callback from a libssl handle. The symbol is located in libcrypto and NOT in libssl. Because libssl is dynamically linked to libcrypto I would expect the loader is able to find the symbol, but that's not the case on freebsd. cheers simon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dlsym() on implicit loaded symbols
Roland Dittel wrote: We have a issue with dlsym() on symbols imported by a library that was loaded with dlopen(). Our code loads the libssl with dlopen() and then do a dlsym() on several symbols. This works for all symbols exported by libssl itself but fails for symbols exported by libcrypto. [..] func = dlsym(handle, CRYPTO_set_id_callback); you have to use RTLD_DEFAULT instead of handle, but I agree, this is not in conformance with SUSv3: The dlsym() function shall search for the named symbol in all objects loaded automatically as a result of loading the object referenced by handle (see dlopen()). Load ordering is used in dlsym() operations upon the global symbol object. The symbol resolution algorithm used shall be dependency order as described in dlopen(). The RTLD_DEFAULT and RTLD_NEXT flags are reserved for future use. Note in all objects loaded automatically. Good catch! cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
Re: dlsym() on implicit loaded symbols
Am 16.07.2006 um 14:33 schrieb Simon 'corecode' Schubert: Roland Dittel wrote: We have a issue with dlsym() on symbols imported by a library that was loaded with dlopen(). Our code loads the libssl with dlopen() and then do a dlsym() on several symbols. This works for all symbols exported by libssl itself but fails for symbols exported by libcrypto. [..] func = dlsym(handle, CRYPTO_set_id_callback); you have to use RTLD_DEFAULT instead of handle, but I agree, this is not in conformance with SUSv3: That's it. Thank you very much. Roland The dlsym() function shall search for the named symbol in all objects loaded automatically as a result of loading the object referenced by handle (see dlopen()). Load ordering is used in dlsym() operations upon the global symbol object. The symbol resolution algorithm used shall be dependency order as described in dlopen(). The RTLD_DEFAULT and RTLD_NEXT flags are reserved for future use. Note in all objects loaded automatically. Good catch! cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dlsym() on implicit loaded symbols
Roland Dittel wrote: Hi all, We have a issue with dlsym() on symbols imported by a library that was loaded with dlopen(). Our code loads the libssl with dlopen() and then do a dlsym() on several symbols. This works for all symbols exported by libssl itself but fails for symbols exported by libcrypto. Libssl is dynamically linked to libcrypto and should be loaded for libssl. I did a truss and the FreeBSD loader loads libcrypto but does not read anything from the file pointer. could you post a sample code fragment which illustrates the problem you are seeing? cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
