From owner-freebsd-stable@freebsd.org Sun Sep 2 12:06:16 2018 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2A72FEDC1D for ; Sun, 2 Sep 2018 12:06:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 3E2DD766B3 for ; Sun, 2 Sep 2018 12:06:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w82C65m5067490 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Sep 2018 15:06:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w82C65m5067490 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w82C63mm067489; Sun, 2 Sep 2018 15:06:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 2 Sep 2018 15:06:03 +0300 From: Konstantin Belousov To: Andreas Longwitz Cc: freebsd-stable@freebsd.org Subject: Re: Constraints in libmap(32).conf do not work as expected, possible bug in rtld-elf Message-ID: <20180902120603.GI2340@kib.kiev.ua> References: <5B89C1E7.4090002@incore.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B89C1E7.4090002@incore.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 12:06:17 -0000 On Sat, Sep 01, 2018 at 12:32:07AM +0200, Andreas Longwitz wrote: > On a FreeBSD 10.4-STABLE r337823 (amd64) server I have to run some old > php52 scripts from an FreeBSD 8.4-STABLE r284383 (i386) server. I have > copied the old php software to /usr/local/php52, installed the ports > misc/compat8x and misc/compat9x and have copied all missing 32-bit > libraries from the old machine to /usr/local/lib32. With the following > libmap32.conf everything works fine: > > ## php52 > /usr/local/lib /usr/local/lib32 > /usr/local/lib/mysql /usr/local/lib32/mysql > > Two examples: > > -> ldd /usr/local/php52/bin/php > /usr/local/php52/bin/php: > libcrypt.so.5 => /usr/lib32/libcrypt.so.5 (0x28273000) > librt.so.1 => /usr/lib32/librt.so.1 (0x28292000) > libm.so.5 => /usr/lib32/libm.so.5 (0x28298000) > libxml2.so.5 => /usr/local/lib32/libxml2.so.5 (0x282c2000) > libz.so.5 => /usr/local/lib32/compat/libz.so.5 (0x283ec000) > libiconv.so.3 => /usr/local/lib32/libiconv.so.3 (0x283fe000) > libc.so.7 => /usr/lib32/libc.so.7 (0x284f2000) > libthr.so.3 => /usr/lib32/libthr.so.3 (0x2866c000) > > -> ldd /usr/local/php52/lib/php/20060613/mysql.so > /usr/local/php52/lib/php/20060613/mysql.so: > libmysqlclient.so.16 => > /usr/local/lib32/mysql/libmysqlclient.so.16 (0x28206000) > libc.so.7 => /usr/lib32/libc.so.7 (0x28070000) > libcrypt.so.5 => /usr/lib32/libcrypt.so.5 (0x2835e000) > libm.so.5 => /usr/lib32/libm.so.5 (0x2837d000) > libz.so.5 => /usr/local/lib32/compat/libz.so.5 (0x283a7000) > librt.so.1 => /usr/lib32/librt.so.1 (0x283b9000) > libthr.so.3 => /usr/lib32/libthr.so.3 (0x283bf000) > > Because I like to use constraints in libmap32.conf I chenged the file to > > ## php52 > [/usr/local/php52/] > /usr/local/lib /usr/local/lib32 > > [/usr/local/php52/lib/php/20060613/mysql.so] > /usr/local/lib/mysql /usr/local/lib32/mysql > > The same examples as above shows that libmap does not work anymore: > > -> ldd /usr/local/php52/bin/php > /usr/local/php52/bin/php: > libcrypt.so.5 => /usr/lib32/libcrypt.so.5 (0x28273000) > librt.so.1 => /usr/lib32/librt.so.1 (0x28292000) > libm.so.5 => /usr/lib32/libm.so.5 (0x28298000) > libxml2.so.5 => not found (0) > libz.so.5 => /usr/local/lib32/compat/libz.so.5 (0x282c2000) > libiconv.so.3 => not found (0) > libc.so.7 => /usr/lib32/libc.so.7 (0x282d4000) > libthr.so.3 => /usr/lib32/libthr.so.3 (0x2844e000) > > -> ldd /usr/local/php52/lib/php/20060613/mysql.so > /usr/local/php52/lib/php/20060613/mysql.so: > libmysqlclient.so.16 => not found (0) > libc.so.7 => /usr/lib32/libc.so.7 (0x28070000) > > The constraints in libmap.conf are handled in rtld-elf with the help of > contexts, and especially a "$DEFAULT$" context is used for all entries > in libmap.conf before the first constraint statement. Now when rtld-elf > loads a program the mapping rules from libmap.conf are applied. In a > first step rtld-elf does a direct mapping using the correct context. But > in a second step called "Searching for ..." rtld-elf uses always the > "$DEFAULT$" context, which in the last example is empty. Therfore > rtld-elf does never find a library in his searching step and cannot load > programs where searching for libraries is necessary. > > I cannot see any reason why rtld-elf should change the context between > step1 and step2, The following patch provokes that rtld-elf uses the > context from step1 in step2 too: I am having problem understanding what do you mean by step1/step2. The refobj reference that you cache in the patch, comes into load_object() as the pointer to the object which initiate the load_object() call. It is NULL for preloaded objects, otherwise it is not. So, could you, please, explain where does it get passed as NULL in your case ? Also, your patch makes the ref_object stuck for all future invocations of the load_object(), so it cannot be correct for this reason alone. Another note is that libmap.conf use that you put it for, is quite the strengthen of the original purpose. You should just add the pathes with your libraries to LD_32_LIBRARY_PATH or configure them into /var/run/ld-elf32.so.hints using 'ldconfig -32'. > > --- rtld.c.orig 2018-03-20 16:56:48.000000000 +0100 > +++ rtld.c 2018-08-31 23:17:18.051206000 +0200 > @@ -186,6 +186,7 @@ > static Obj_Entry obj_rtld; /* The dynamic linker shared object */ > static unsigned int obj_count; /* Number of objects in obj_list */ > static unsigned int obj_loads; /* Number of loads of objects (gen count) */ > +static char *save_refobj_path; > > static Objlist list_global = /* Objects dlopened with RTLD_GLOBAL */ > STAILQ_HEAD_INITIALIZER(list_global); > @@ -1499,6 +1500,7 @@ > if (libmap_disable || !objgiven || > (name = lm_find(refobj->path, xname)) == NULL) > name = (char *)xname; > + save_refobj_path = refobj->path; > > dbg(" Searching for \"%s\"", name); > > @@ -2831,7 +2833,7 @@ > char *res; > > len = strcspn(path, ":;"); > - trans = lm_findn(NULL, path, len); > + trans = lm_findn(save_refobj_path, path, len); > if (trans) > res = callback(trans, strlen(trans), arg); > else > > This patch solves the described problem for me.