Date: Wed, 30 Nov 2016 14:19:08 +0100 From: Matthieu Volat <mazhe@alkumuna.eu> To: Konstantin Belousov <kostikbel@gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <kostikbel@gmail.com> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161130141908.31ecba84>