From owner-freebsd-stable Tue Dec 11 14:50:11 2001 Delivered-To: freebsd-stable@freebsd.org Received: from zircon.seattle.wa.us (sense-sea-CovadSub-0-228.oz.net [216.39.147.228]) by hub.freebsd.org (Postfix) with SMTP id E91C737B419 for ; Tue, 11 Dec 2001 14:49:44 -0800 (PST) Received: (qmail 18109 invoked by uid 1001); 11 Dec 2001 22:51:31 -0000 From: Joe Kelsey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15382.36337.945315.693398@zircon.zircon.seattle.wa.us> Date: Tue, 11 Dec 2001 14:51:29 -0800 To: freebsd-stable@freebsd.org Subject: rtld-elf issues X-Mailer: VM 6.98 under Emacs 21.1.1 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG What should rtld-elf do when asked to load an already loaded shared object? Currently, if you manually request loading of a shared object via dlopen, rtld-elf will recursively try to load any libraries that the shared object references. If the shared library references an already manually-loaded shared object, it still attempts to find the shared object via the various paths in effect at the time of the dlopen call. This is an unnecessary effort, since the module is already loaded, yet the search can fail and abort the program due to phantom dlopen errors. The reason that this is important is because of legacy linker commands in programs ported from Solaris and Linux, in particular the Java Mozilla plugin. For various obscure reasons, shared objects created by the default linker commands for the Java plugin reference a specific libjvm.so, even though the actual libjvm.so (green or native threads) is determined at run time and manually loaded. When the rtld-elf functions attempt to load one of these shared objects (libjavaplugin_jni.so for instance), it encounters the reference to libjvm.so and attempts to find it in the default LD_LIBRARY_PATH in effect at the time. However, libjvm.so is *not* in the LD_LIBRARY_PATH, since Java applications have to manually specify their threading model at run time, and the green vs. native selection is done prior to loading this particular shared object. Shouldn't the loader notice that libjvm.so is already mapped into the address space and skip checking for it on the disk? Presumably, although I haven't verified this in the rtld code, it would eventually find out the the library is already loaded further down the road when it actually attempts to map and already mapped file. If this is not the appropriate forum to raise this question, please let me know where to raise it. /Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message