From owner-freebsd-arm@FreeBSD.ORG Thu Jun 18 06:08:44 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1C7F106564A; Thu, 18 Jun 2009 06:08:44 +0000 (UTC) (envelope-from venkiece2005@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id 9A27D8FC17; Thu, 18 Jun 2009 06:08:44 +0000 (UTC) (envelope-from venkiece2005@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so378296ywe.13 for ; Wed, 17 Jun 2009 23:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=s8zhDn8rrvCuPHM2e9iqSeXA7gDNAOa1dh+EIT/uHJw=; b=FSa3K6PyTFfrRSTr0ZIHx3Rkh0AMfCQKPUf+SGRmL/Sqb7L8fHW5wxRaxZ6j8l/lMR 8pqTRa7xTTWzNlZJktI4qgmudSQ43LTYhe0r4klMUZghJD6wHrR9oPbLIzkkL5j2ieqz DHabx7XivIZViPEwABCUnHR5m5mWqrOkEMhpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=svxN2eU5ANiiqmgp8g/vLFtYMlsRP2ZkobBVl4czWPu/H+YGJ7aFnKpGx7Vnr2ejCK /wqyljps/meM+wh/p3XOrwcy/ynVTtMENRfQB3TJu0M4Kn0PqEiTc7gQGcSd6CGtugx2 NCGl37dTMqwEhAKrKy6FUZQnjGGTb/WD4AKRA= MIME-Version: 1.0 Received: by 10.151.119.2 with SMTP id w2mr2803496ybm.200.1245305323438; Wed, 17 Jun 2009 23:08:43 -0700 (PDT) In-Reply-To: <20090616200756.70206fda@kan.dnsalias.net> References: <6d53329e0906160229j2fdba518h84b13652153a32f6@mail.gmail.com> <20090616200756.70206fda@kan.dnsalias.net> Date: Thu, 18 Jun 2009 11:38:43 +0530 Message-ID: <6d53329e0906172308j28c7f404y49f759fea4842a29@mail.gmail.com> From: venki kaps To: Alexander Kabaev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org, netbsd-users@netbsd.org Subject: Re: [libc] dlclose gives "invalid shared object handle" without pthread combination. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 06:08:45 -0000 Hi, I have been porting NetBSD source in the Linux environment with our own pthread library. system environment: Compiler: arm-linux-gcc-4.3.3 OS: Linux Kernel: 2.6.29 Yes, it never even calls dlerr() in dlcose but NetBSD __dlclose(void *handle) source sequence, int dlclose(void *handle) { Obj_Entry *root = _rtld_dlcheck(handle); if (root == NULL) return -1; _rtld_debug.r_state = RT_DELETE; _rtld_debug_state(); --root->dl_refcount; _rtld_unload_object(root, true); _rtld_debug.r_state = RT_CONSISTENT; _rtld_debug_state(); return 0; } static Obj_Entry * _rtld_dlcheck(void *handle) { Obj_Entry *obj; for (obj = _rtld_objlist; obj != NULL; obj = obj->next) if (obj == (Obj_Entry *) handle) break; xprintf("obj->dl_refcount is %d\n",obj->dl_refcount); if (obj == NULL || obj->dl_refcount == 0) { xwarnx("Invalid shared object handle %p", handle); return NULL; } return obj; } I have printed xprintf("obj->dl_refcount is %d\n",obj->dl_refcount); obj->dl_refcount is getting zero(0). So due to "obj->dl_refcount == 0" the error "invalid shared object handle" is showing. i do not know why this error is coming even though all the constructor/destructor sequences are completed. is it rtld_exit->fini->static C++ destructor->dlcose sequence problem? Thanks & Regards, Venkappa On Wed, Jun 17, 2009 at 5:37 AM, Alexander Kabaev wrote: > Hi, > > I do not think we on FreeBSD support NetBSD rtld with our pthread > libraries, unless you already implemented all the necessary glue. > The interface between threading library and rtld is rather intimate and > tricky to get right. > > You provide no code to look at nor explicitly mention what OS and > what version you are running your test on (FreeBSD?), I think you are > on your own. Furthermore, your claim on 'correct' > constructor/destructor is wrong given the sample code provided by > NetBSD PR. > > Some more comments are inline. > > On Tue, 16 Jun 2009 14:59:36 +0530 > venki kaps wrote: > >> Hi, >> >> I am using the NetBSD implementation of rtld(src/libexec/ld.elf_so/) >> for ARM/MIPS. >> >> I have C++ static constructor/destructor issue with my rtld. >> >> Problem Report: >> "ld.elf_so does not execute .init/.fini functions in order" and [libc] >> dlclose gives >> "invalid shared object handle" when called through the fini function >> of another module. >> >> The similar NetBSD/freeBSD issues are found from the following >> References: [1] http://gnats.netbsd.org/37347 >> [2] http://updraft3.jp.freebsd.org/cgi/query-pr.cgi?pr=kern/42956 >> >> The above issues are already commited in NetBSD-5-0-RELEASE. >> >> I have ported NetBSD-5-0-RELEASE rtld and tested Ref[1] provided >> static constructor/destructor test and did not find any issues >> with shared pthread combination but noticed [libc] dlclose gives >> "invalid shared object handle" without pthread combination. >> >> The static constructor/destructor test results: >> >> It should be : >> -------------- >> >> $ ./foobar >> foo_ctor >> bar_ctor >> tar_ctor >> main_ctor >> dep1_ctor >> dep2_ctor >> dll_ctor >> dll_dtor >> dep2_dtor >> dep1_dtor >> main_dtor >> tar_dtor >> bar_dtor >> foo_dtor > > Given the test in Ref[1], both constructor and destructor orders are > wrong above. libdep1 depends on libdep2, so dep2_ctor should be invoked > before dep1_ctor and consequently dep2_dtor should be invoked after > dep1_dtor. > >> While currently I get: >> ---------------------- >> >> with pthreads: >> >> $ ./foobar >> foo_ctor >> bar_ctor >> tar_ctor >> main_ctor >> dep1_ctor >> dep2_ctor >> dll_ctor >> dll_dtor >> dep2_dtor >> dep1_dtor >> main_dtor >> tar_dtor >> bar_dtor >> foo_dtor >> >> without pthreads: >> >> $ ./foobar >> foo_ctor >> bar_ctor >> tar_ctor >> main_ctor >> dep1_ctor >> dep2_ctor >> dll_ctor >> dll_dtor >> dep2_dtor >> dep1_dtor >> main_dtor >> tar_dtor >> bar_dtor >> foo_dtor >> Invalid shared object handle 0xbdbed400 > > Again, given the sample code from NetBSD PR cannot possibly print this > message because it never even calls dlerr(). You must be looking at > some other code and unless you provide it, understanding your problem > and fixing it is next to impossible. > > Said that, thanks for pointing the FreeBSD PR to me. I will commit the > fix for the problem described here shortly. > >> This gives a "invalid shared object handle" message >> because the refcount field (obj->dl_refcount) for the handle is zero. >> >> I have little bit confused about dlclose destructor >> with/without pthreads. >> >> I have some queries: >> 1) Is it required any changes apart from the >> NetBSD-5-0-RELEASE/{Ref[1],[2]}? 2) Are any changes required in >> thread-stub? >> >> Could anyone provide any inputs to the my issue? >> >> Thanks in advance. >> >> Thanks & Regards, >> Venkappa > > -- > Alexander Kabaev >