From owner-svn-src-all@freebsd.org Mon Jun 15 19:31:50 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 155D93413FE; Mon, 15 Jun 2020 19:31:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49m1fs3G8Hz4dss; Mon, 15 Jun 2020 19:31:49 +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 05FJVeUa090343 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 15 Jun 2020 22:31:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 05FJVeUa090343 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 05FJVePo090342; Mon, 15 Jun 2020 22:31:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 15 Jun 2020 22:31:40 +0300 From: Konstantin Belousov To: John Baldwin Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r362152 - head/usr.bin/ldd Message-ID: <20200615193140.GB45690@kib.kiev.ua> References: <202006131821.05DILVnR053798@repo.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 49m1fs3G8Hz4dss X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; REPLY(-4.00)[] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 19:31:50 -0000 On Mon, Jun 15, 2020 at 11:45:31AM -0700, John Baldwin wrote: > On 6/13/20 11:21 AM, Konstantin Belousov wrote: > > Author: kib > > Date: Sat Jun 13 18:21:31 2020 > > New Revision: 362152 > > URL: https://svnweb.freebsd.org/changeset/base/362152 > > > > Log: > > Fix ldd for PIE binaries after rtld stopped accepting binaries for dlopen. > > > > ldd proclaims ET_DYN objects as shared libraries and tries to > > dlopen(RTLD_TRACE) them to get dependencies. Since PIE binaries are > > ET_DYN | DF_1_PIE, refusal to dlopen such binaries breaks ldd. > > > > Fix it by reading and parsing dynamic segment looking for DF_FLAG_1 > > and taking DF_1_PIE into account when deciding between binary and > > library. > > Hmmm, I have an alternate patch for this that instead depends on the > present of PT_INTERP (since we already look at program headers) to > determine PIE vs not-PIE. >From my understanding of some discussions on the ABI list PT_INTERP is not the characteristic property of the binary. Instead it is ET_EXEC | (ET_DYN && DF_1_PIE), i.e. this is the reason why the flag was added. > This has the advantage of working for older > binaries since DF_1_PIE is relatively recent. (I had also changed it to > use libelf to reduce code duplication for the 32-bit compat stuff, but > it was pending on getting the branding sorted out since it still doesn't > fully work for RISC-V and aarch64 shared libraries until they are > branded as the patches also look at notes sections to check for the > FreeBSD ABI note tag to decide if a shared library is a FreeBSD one that > can be passed to dlopen()). Initially I considered to just reenable dlopening ET_DYN && DF_1_PIE for tracing. After your note about old binaries without DF_1_PIE, I think it is even better idea. I do not have an opinion on use of libelf in ldd. It is fine, perhaps, since I do not think about ldd as anything fundamental, just a convenience wrapper around rtld. So one more dependency for ldd is not that critical.