From owner-freebsd-java@freebsd.org Wed Nov 30 13:19:21 2016 Return-Path: Delivered-To: freebsd-java@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 881C3C5D352 for ; Wed, 30 Nov 2016 13:19:21 +0000 (UTC) (envelope-from mazhe@alkumuna.eu) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 503031BC5 for ; Wed, 30 Nov 2016 13:19:21 +0000 (UTC) (envelope-from mazhe@alkumuna.eu) Received: from yggdrasil.alkumuna.eu (unknown [IPv6:2a01:e35:8a74:6e70:232:36ff:fe5c:3a87]) by smtp1-g21.free.fr (Postfix) with ESMTPS id 159D4B00350; Wed, 30 Nov 2016 14:19:15 +0100 (CET) Received: from freedom.alkumuna.eu ([IPv6:2a01:e35:8a74:6e70:62a4:4cff:fe54:b212]) (authenticated bits=0) by yggdrasil.alkumuna.eu (8.15.2/8.15.2) with ESMTPSA id uAUDJBAL089595 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Nov 2016 14:19:15 +0100 (CET) (envelope-from mazhe@alkumuna.eu) Date: Wed, 30 Nov 2016 14:19:08 +0100 From: Matthieu Volat To: Konstantin Belousov Cc: freebsd-java@freebsd.org Subject: Re: Trying to locate function using dlfunc with RLTD_NEXT from JNI Message-ID: <20161130141908.31ecba84@freedom.alkumuna.eu> In-Reply-To: <20161130130036.GA54029@kib.kiev.ua> References: <20161130115920.444d7a76@freedom.alkumuna.eu> <20161130130036.GA54029@kib.kiev.ua> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/FzgeZxttZLZOM+pqJ7_x6zE"; protocol="application/pgp-signature" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkumuna.eu; s=default; t=1480511955; bh=SO8p3WmlPBnhihTMyCS6pRpILiQZj2ZzjAUObQRT/Jg=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:MIME-Version:Content-Type; b=OyDqpyGnn06SUikZVh6uFGxEAtUdE8W1cls/eKSIUlxKQebZuTy7TPIyw8Q0YNMR76ySndN/DIRrCs7fpOC+zJf4k62Lq/nYcY3PNM50ZJluOdIGbuSeznbUdK/Um1eiBfVCs+L5ubyqkTAv35ROY2hWRStSsORM98E9WjZqMm8= X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 13:19:21 -0000 --Sig_/FzgeZxttZLZOM+pqJ7_x6zE Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 30 Nov 2016 15:00:36 +0200 Konstantin Belousov wrote: > On Wed, Nov 30, 2016 at 11:59:20AM +0100, Matthieu Volat wrote: > > Hi, a (maybe not) tricky question for people who know well the internal= s of the jdk on freebsd... > >=20 > > Trying to port a linux project that does quite a bit of introspection, = begining by using malloc & co wrapper, with java binding, I found that stra= ngely, you can use dlfunc(RTLD_NEXT, "malloc") in a non-java environment...= But as soon as this code is loaded in the context of the jvm, the symbol w= on't be resolved. > >=20 > > This is maybe a bit suprising as this technique worked on Linux and I d= id not expect much difference here... > >=20 > > Small demonstration code: > >=20 > > % git clone https://gist.github.com/f6993d7a48ecbab6c0c979b9a7a40912.= git jni_dlfunc > > % cd jni_dlfunc > > % make > > [...] > > % ./testfoo=20 > > malloc function located at 0x800ade210 > > % java -Djava.library.path=3D. testfoo > > could not locate function malloc: Undefined symbol "malloc" > >=20 > > Would anybody have an idea of why the jvm would cause the C symbols not= to be found via RTLD_NEXT and if there would be a way to workaround it (th= at is not to load explicitely "/lib/libc.so.7")? > >=20 > It does not work because libc.so is loaded before your dso in the global > dso order. Look carefully at the description of the RTLD_NEXT constant. >=20 > Why cannot you use RTLD_DEFAULT special there ? Thanks. RTLD_DEFAULT would find the wrapper function and so the program wou= ld enter a loop of malloc() calling itself. I was less suprised by the result than by the different behavior between ja= va/linux and java/freebsd in that case... They must be doing some reorderin= g I guess... --Sig_/FzgeZxttZLZOM+pqJ7_x6zE Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTxuiqPSkQnzRDOjsP4Q0N5gpmLfgUCWD7RzQAKCRD4Q0N5gpmL fvAiAKCYu8mgUwCdis+5atNzJE7rOw2O0ACdHIGe8FjDTH7w20O/Tme+eqQRYuY= =EyoS -----END PGP SIGNATURE----- --Sig_/FzgeZxttZLZOM+pqJ7_x6zE--