From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 17 00:45:45 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 182F33CF; Thu, 17 Jul 2014 00:45:45 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ABF4A26A6; Thu, 17 Jul 2014 00:45:44 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s6H0jbRq039068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jul 2014 03:45:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s6H0jbRq039068 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s6H0jbsa039066; Thu, 17 Jul 2014 03:45:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 17 Jul 2014 03:45:37 +0300 From: Konstantin Belousov To: Ian Lepore Subject: Re: [CFR] Adding a function to rtld-elf.so, how to handle Symbol.map? Message-ID: <20140717004537.GE93733@kib.kiev.ua> References: <1405545833.1312.84.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LgQaYbqhrDFEl/u2" Content-Disposition: inline In-Reply-To: <1405545833.1312.84.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 00:45:45 -0000 --LgQaYbqhrDFEl/u2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 16, 2014 at 03:23:53PM -0600, Ian Lepore wrote: > I need to add an ARM-specific function to rtld-elf.so to help locate > exception unwind info in shared objects. I'm confused about how to add > the function to Symbol.map... do I have to add a 1.4 section because it > was first added in FreeBSD 11, or does it go into an existing section > because it doesn't introduce changes to an existing ABI? >=20 > -- Ian >=20 There is no sense in continuing iterating if the pc value falls into the segment range, but segment does not have PF_X permission bit; there may be at most one segment mapped at the given address. That said, the _rtld_addr_phdr() is more suitable function to use for findexcb(), since it provides you with the needed object directly, without iterating on the previously loaded objects. Why do you need the __gnu_Unwind_Find_exidx() be the part of rtld ? I do not see a reason for e.g. libc/arm not be a good home for the function. We try to not extend the ABI of rtld unless there are very strong reasons. The function implementation does not use any internal rtld structures, only external interfaces. What is the supposed use of the function ? Are the consumers of it only the system libraries, or is it planned that user binaries will reference the symbol directly from their symbol table ? If first, the place for the symbol is FBSDprivate_1.0 namespace. If it must be used directly by binaries for which we provide ABI stability guarantees, than FBSD_1.4 is the correct namespace to put the symbol into, regardless of the shared object which would provide it. > diff -r 63a383d5fd3e libexec/rtld-elf/Symbol.map > --- libexec/rtld-elf/Symbol.map Thu May 01 08:14:39 2014 -0600 > +++ libexec/rtld-elf/Symbol.map Wed Jul 16 15:06:30 2014 -0600 > @@ -20,6 +20,7 @@ FBSD_1.0 { > =20 > FBSD_1.3 { > fdlopen; > + __gnu_Unwind_Find_exidx; > }; > =20 > FBSDprivate_1.0 { > diff -r 63a383d5fd3e libexec/rtld-elf/arm/Makefile.inc > --- libexec/rtld-elf/arm/Makefile.inc Thu May 01 08:14:39 2014 -0600 > +++ libexec/rtld-elf/arm/Makefile.inc Wed Jul 16 15:06:30 2014 -0600 > @@ -1,1 +1,5 @@ > # $FreeBSD: head/libexec/rtld-elf/arm/Makefile.inc 130646 2004-06-17 17:= 53:16Z cognet $ > + > +SRCS+=3D find_exidx.c > +CFLAGS+=3D -I${TOPSRCDIR}/contrib/libexecinfo > + > diff -r 63a383d5fd3e libexec/rtld-elf/arm/find_exidx.c > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ libexec/rtld-elf/arm/find_exidx.c Wed Jul 16 15:06:30 2014 -0600 > @@ -0,0 +1,103 @@ > +/*- > + * Copyright (c) 2014 Ian Lepore > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + * notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > + * notice, this list of conditions and the following disclaimer in the > + * documentation and/or other materials provided with the distributio= n. > + * > + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND > + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PU= RPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIAB= LE > + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUE= NTIAL > + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOO= DS > + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, S= TRICT > + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY= WAY > + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > + * SUCH DAMAGE. > + */ > + > +#include > +__FBSDID("$FreeBSD$"); > + > +#include > +#include > +#include > +#include > +#include > +#include /* This is contrib/libexecinfo/unwind.h */ > + > +/* > + * ARM EABI unwind helper for dynamically linked code. > + * > + * This code iterates all shared objects that have been loaded, looking = for one > + * whose in-memory text address range contains the given PC. It returns= the > + * address of the exidx section in that shared object along with the num= ber of > + * entries in that section, or NULL if it wasn't found. This overrides a > + * weak-linkage default implementation in the unwinder library that only= works > + * for a static-linked application. > + */ > + > +struct cbdata { > + _Unwind_Ptr pc; > + _Unwind_Ptr exptr; > + int excount; > +}; > + > +static int > +findexcb(struct dl_phdr_info *info, size_t size, void *data) > +{ > + struct cbdata * cbd; > + const Elf_Phdr *hdr; > + Elf_Addr exptr, pc, vaddr; > + Elf_Word len; > + int i, exlen, found; > + const int FOUND_PC =3D 0x01; > + const int FOUND_EX =3D 0x02; > + const int SIZEOF_EIT_ENTRY =3D 8; /* Not available in a header file. */ > + > + cbd =3D data; > + found =3D 0; > + pc =3D (Elf_Addr)cbd->pc; > + for (i =3D 0, hdr =3D info->dlpi_phdr; i < info->dlpi_phnum; i++, hdr++= ) { > + vaddr =3D info->dlpi_addr + hdr->p_vaddr; > + len =3D hdr->p_memsz; > + if (hdr->p_type =3D=3D PT_LOAD && (hdr->p_flags & PF_X) !=3D 0 && > + pc >=3D vaddr && pc < vaddr + len) { > + found |=3D FOUND_PC; > + } else if (hdr->p_type =3D=3D PT_ARM_EXIDX) { > + found |=3D FOUND_EX; > + exptr =3D vaddr; > + exlen =3D len; > + } > + if (found =3D=3D (FOUND_PC | FOUND_EX)) { > + cbd->exptr =3D (_Unwind_Ptr)(exptr); > + cbd->excount =3D exlen / SIZEOF_EIT_ENTRY; > + return (1); /* Stop iterating. */ > + } > + } > + return (0); /* Continue iterating with next object. */ > + > +} > + > +_Unwind_Ptr > +__gnu_Unwind_Find_exidx(_Unwind_Ptr pc, int * pcount) > +{ > + struct cbdata cbd; > + > + cbd.pc =3D pc; > + cbd.exptr =3D NULL; > + cbd.excount =3D 0; > + dl_iterate_phdr(findexcb, &cbd); > + if (cbd.exptr !=3D NULL) > + *pcount =3D cbd.excount; > + return (cbd.exptr); > +} > + > diff -r 63a383d5fd3e sys/arm/include/elf.h > --- a/sys/arm/include/elf.h Thu May 01 08:14:39 2014 -0600 > +++ b/sys/arm/include/elf.h Wed Jul 16 15:06:30 2014 -0600 > @@ -55,6 +55,9 @@ typedef struct { /* Auxiliary vec > =20 > #define ELF_MACHINE_OK(x) ((x) =3D=3D EM_ARM) > =20 > +/* Unwind info section type */ > +#define PT_ARM_EXIDX (PT_LOPROC + 1) > + > /* > * Relocation types. > */ > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --LgQaYbqhrDFEl/u2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTxxywAAoJEJDCuSvBvK1B9BMP/1oKtgqaMfjYBAQOKrYJC9UN z5ttsdEssRNNco+uEQz1RZjhZ1vnCk4FDR6PhTH/R5ADVUdzeIBPrks3etKe9uKb F1wMolPyV3DLRkRX8+B/qa6i+XwMCIeEc4wAC9/6ZL7TyNrIzcWz66a+Hq07F7or Ja0N/qsnCGNxyXp57GcvEpog95EvMyGWj3mOcH8XO8owoPBZYGa4vvESKdiP3YaZ QTIoi/kbIA/3oLkbhTE7p+DY/eZY7CBPcaT/TxqDGWZY5uyaYhnKYjjDZwZOmQYD ojj66YZLJU9KhkT3QL+KryNbXqvH+6b9ri21iRZOnU0VX71EdB9DRs6iv2i1VDUU arl6OrzO4SvUWpwNRtd7n2gaeOuxy6lItsFflkY1enh7fp/drzAJRrOO9NbNH41G 2oQSTETZTknfmYn3rEbJltBG3cytH7VbuTsO91AUXMMkmGt/0evbF8y9/qFz4JMg ChhRjwC69JHpZDY3on2p9m7d2eibAeux7EcLLm5zfV9ytyYUKuI4KWnvVF6hw+0G b70ZUkbV2Mnx5ViyWFYMuenMre7KQwLColfReRUuaMf4LcCFXEUk3LN6bsRU3Y2j J8RmX0M1KnG3cvMNZXzVnNGuE/PuXccl8NVxenB52yfxw67InC1y7A7ZY3IUrXJb G/keycMglBUR9UkqWGrK =wq5B -----END PGP SIGNATURE----- --LgQaYbqhrDFEl/u2-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 17 04:58:24 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E9B0513 for ; Thu, 17 Jul 2014 04:58:24 +0000 (UTC) Received: from kithrup.com (Kithrup.COM [64.142.31.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1DB7F29EF for ; Thu, 17 Jul 2014 04:58:24 +0000 (UTC) Received: from kithrup.com (localhost [127.0.0.1]) by kithrup.com (8.14.4/8.14.4) with ESMTP id s6H4wNWl018571 for ; Wed, 16 Jul 2014 21:58:23 -0700 (PDT) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.14.4/8.14.4/Submit) id s6H4wNWK018570; Wed, 16 Jul 2014 21:58:23 -0700 (PDT) (envelope-from sef) Date: Wed, 16 Jul 2014 21:58:23 -0700 (PDT) From: Sean Eric Fagan Message-Id: <201407170458.s6H4wNWK018570@kithrup.com> To: hackers@freebsd.org Subject: Re: Expanding on NO_ROOT: Categorizing installed files X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 04:58:24 -0000 >Picking a random example: how is this different/better than the existing >DISTRIBUTION variable? More flexible and finely-tuned. From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 17 17:10:00 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 021EED47 for ; Thu, 17 Jul 2014 17:10:00 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8FBC2BAF for ; Thu, 17 Jul 2014 17:09:59 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X7pBo-0001K6-2H; Thu, 17 Jul 2014 17:09:52 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6HH9o1X018566; Thu, 17 Jul 2014 11:09:50 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1862i/F6wn1ft0iImYDPlP5 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [CFR] Adding a function to rtld-elf.so, how to handle Symbol.map? From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20140717004537.GE93733@kib.kiev.ua> References: <1405545833.1312.84.camel@revolution.hippie.lan> <20140717004537.GE93733@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jul 2014 11:09:50 -0600 Message-ID: <1405616990.1312.111.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 17:10:00 -0000 On Thu, 2014-07-17 at 03:45 +0300, Konstantin Belousov wrote: > On Wed, Jul 16, 2014 at 03:23:53PM -0600, Ian Lepore wrote: > > I need to add an ARM-specific function to rtld-elf.so to help locate > > exception unwind info in shared objects. I'm confused about how to add > > the function to Symbol.map... do I have to add a 1.4 section because it > > was first added in FreeBSD 11, or does it go into an existing section > > because it doesn't introduce changes to an existing ABI? > > > > -- Ian > > > There is no sense in continuing iterating if the pc value falls into the > segment range, but segment does not have PF_X permission bit; there may > be at most one segment mapped at the given address. That said, the > _rtld_addr_phdr() is more suitable function to use for findexcb(), since > it provides you with the needed object directly, without iterating on > the previously loaded objects. > Oh, I didn't know about _rtld_addr_phdr(), I'll rewrite it using that to do the iteration part for me. > Why do you need the __gnu_Unwind_Find_exidx() be the part of rtld ? > I do not see a reason for e.g. libc/arm not be a good home for the > function. We try to not extend the ABI of rtld unless there are > very strong reasons. The function implementation does not use any > internal rtld structures, only external interfaces. > There is a default version of this function which works only for statically linked apps in contrib/gcc/config/arm/unwind-arm.c, defined with __attribute__((weak)). For dynamically linked apps, a replacement version needs to override the weak-linkage default to find the exidx data in one of the loaded objects. The scheme is similar to the stuff in libc/gen/dlfcn.c. I did some looking around and Netbsd, Android, and Risc Os all implemented this in their dynamic loaders, so that seemed like the way to go. Android actually puts a function with this __gnu name in its libc, but all that function does is calls dl_unwind_find_exidx() which is implemented in their loader. I've just discovered that the arm unwind support code that will arrive as part of clang 3.5 appears to assume the Android way of things unless __LINUX__ is defined, so maybe it would be good to follow that model ourselves and add a dl_unwind_find_exidx() stub to libc/gen/dlfcn.c and name the new implementation in ld-elf to match. > What is the supposed use of the function ? Are the consumers of it > only the system libraries, or is it planned that user binaries will > reference the symbol directly from their symbol table ? > If first, the place for the symbol is FBSDprivate_1.0 namespace. > If it must be used directly by binaries for which we provide ABI > stability guarantees, than FBSD_1.4 is the correct namespace to > put the symbol into, regardless of the shared object which would > provide it. > The problem I'm working on is making C++ exceptions work on ARM. The exception handling code in the C++ runtime support libraries needs this. It might also be needed by other code/tools that need to generate backtraces or otherwise use the unwind info. I guess I don't know how/where to draw the line between public and private libraries. If someone is using a version of gcc later than 4.2.1, the libraries that are part of that toolchain are going to reference this function name, that feels kind of public to me. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 17 17:29:17 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 706D2F8E; Thu, 17 Jul 2014 17:29:17 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E9E3F2D3B; Thu, 17 Jul 2014 17:29:16 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s6HHTAs8080805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jul 2014 20:29:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s6HHTAs8080805 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s6HHTAqD080804; Thu, 17 Jul 2014 20:29:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 17 Jul 2014 20:29:10 +0300 From: Konstantin Belousov To: Ian Lepore Subject: Re: [CFR] Adding a function to rtld-elf.so, how to handle Symbol.map? Message-ID: <20140717172910.GH93733@kib.kiev.ua> References: <1405545833.1312.84.camel@revolution.hippie.lan> <20140717004537.GE93733@kib.kiev.ua> <1405616990.1312.111.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Wxhx7UDFq2GtZM1i" Content-Disposition: inline In-Reply-To: <1405616990.1312.111.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 17:29:17 -0000 --Wxhx7UDFq2GtZM1i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 17, 2014 at 11:09:50AM -0600, Ian Lepore wrote: > On Thu, 2014-07-17 at 03:45 +0300, Konstantin Belousov wrote: > > On Wed, Jul 16, 2014 at 03:23:53PM -0600, Ian Lepore wrote: > > > I need to add an ARM-specific function to rtld-elf.so to help locate > > > exception unwind info in shared objects. I'm confused about how to a= dd > > > the function to Symbol.map... do I have to add a 1.4 section because = it > > > was first added in FreeBSD 11, or does it go into an existing section > > > because it doesn't introduce changes to an existing ABI? > > >=20 > > > -- Ian > > >=20 > > There is no sense in continuing iterating if the pc value falls into the > > segment range, but segment does not have PF_X permission bit; there may > > be at most one segment mapped at the given address. That said, the > > _rtld_addr_phdr() is more suitable function to use for findexcb(), since > > it provides you with the needed object directly, without iterating on > > the previously loaded objects. > >=20 >=20 > Oh, I didn't know about _rtld_addr_phdr(), I'll rewrite it using that to > do the iteration part for me. The _rtld_addr_phdr() does not iterate. If it did it job by calling dl_iterate_phdr(3), it would be part of libc. >=20 > > Why do you need the __gnu_Unwind_Find_exidx() be the part of rtld ? > > I do not see a reason for e.g. libc/arm not be a good home for the > > function. We try to not extend the ABI of rtld unless there are > > very strong reasons. The function implementation does not use any > > internal rtld structures, only external interfaces. > >=20 >=20 > There is a default version of this function which works only for > statically linked apps in contrib/gcc/config/arm/unwind-arm.c, defined > with __attribute__((weak)). For dynamically linked apps, a replacement > version needs to override the weak-linkage default to find the exidx > data in one of the loaded objects. The scheme is similar to the stuff > in libc/gen/dlfcn.c. Our rtld does not follow ELF standard. There is no requirement that weak symbol has lower resolution priority than non-weak. Basically, libc dlfcn.c relies on the bug. Eventually, this stuff should be only compiled for the libc.a. >=20 > I did some looking around and Netbsd, Android, and Risc Os all > implemented this in their dynamic loaders, so that seemed like the way > to go. Android actually puts a function with this __gnu name in its > libc, but all that function does is calls dl_unwind_find_exidx() which > is implemented in their loader. >=20 > I've just discovered that the arm unwind support code that will arrive > as part of clang 3.5 appears to assume the Android way of things unless > __LINUX__ is defined, so maybe it would be good to follow that model > ourselves and add a dl_unwind_find_exidx() stub to libc/gen/dlfcn.c and > name the new implementation in ld-elf to match. I think that Android/__LINUX__ combination does the right thing, by providing the symbol in libc. A libc implementation does not need any additional service from rtld, except already existing _rtld_addr_phdr(). Also, I recomment you to look at the libc helper __elf_phdr_match_addr =66rom libc/gen/elf_utils.c, which, together with _rtld_addr_phdr(), seemingly implements 70% of your function. That said, please do not put MD function in dlfcn.c, but into a new file in libc/arm/gen/. >=20 > > What is the supposed use of the function ? Are the consumers of it > > only the system libraries, or is it planned that user binaries will > > reference the symbol directly from their symbol table ? >=20 > > If first, the place for the symbol is FBSDprivate_1.0 namespace. > > If it must be used directly by binaries for which we provide ABI > > stability guarantees, than FBSD_1.4 is the correct namespace to > > put the symbol into, regardless of the shared object which would > > provide it. > >=20 >=20 > The problem I'm working on is making C++ exceptions work on ARM. The > exception handling code in the C++ runtime support libraries needs this. > It might also be needed by other code/tools that need to generate > backtraces or otherwise use the unwind info. >=20 > I guess I don't know how/where to draw the line between public and > private libraries. If someone is using a version of gcc later than > 4.2.1, the libraries that are part of that toolchain are going to > reference this function name, that feels kind of public to me. I.e., it is provided so that third-party runtime libraries could use the symbol to do the lookup of exception tables ? This indeed sounds as the public interface, so it should go into FBSD_1.4. --Wxhx7UDFq2GtZM1i Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTyAfmAAoJEJDCuSvBvK1B5xwP/0Ntop7tATcUqGFj9dQewENt ZrKckGYxU5gYgfxySbTmv0J4OFMwliiEwAtKnad9/KCRv2Km5/yfMlgV13kWXh7b E9J8JjKvllxua5hirQGsEgg6HJz+V3F/zAAO1wcua7bNDUxun4il1DCCH3N+r5wo p1Vaj/GkGBPOv+Lcpt41VnVplBt1Kt/n4DUr2p6bZgNc4+dgPXp7lhjbnsZ9DQ2T DTd2c12DUllEQdt/mWFStx8Nt0EZraEeYASylZdH53iI2/Q1ADY5FzNLZnkILEqP X1jnIqsMUctyc9BFqz60snE0mf43b9slsYu7+jBPNKhP/uucend+M1ZWIPTOzq5l rxTLR+cxMBvDGpWkwaTs8LBMYat0yegQgt+ZYi0f70kboKGhjJ9VFBzJyB3CVhVD 4LHVZVKJS2+ABYdVQ2B+kADooZb8Od+ArSu5M6rEazsCrkbAz8JUu5nLcdVYg/4p POuY9qvHRt3bSf4RrkeV1qDGfyZZ0Z+VpbnNSppjLI379VuxzkLACyejz7CjsVz3 TBicfDQjFYp+VAQAXwEmyiXKNoPNi7bIydK2xcb3lVXFs3jo8gW+qJNwyncXY+da Gr0HrjfZzZkoe2yp6hPku1m12Y+J4Xvx6es5HFofs16KzLs8KHyK7YqTWt2/rI5B g0gOas8KumxjCkel9RCT =x51C -----END PGP SIGNATURE----- --Wxhx7UDFq2GtZM1i-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 17 18:10:11 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CDC97FD for ; Thu, 17 Jul 2014 18:10:11 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0A2920B4 for ; Thu, 17 Jul 2014 18:10:10 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X7q89-0008i6-FD; Thu, 17 Jul 2014 18:10:09 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6HIA8Ug018705; Thu, 17 Jul 2014 12:10:08 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19v68YfpB4duUUxBkBZQoFK X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [CFR] Adding a function to rtld-elf.so, how to handle Symbol.map? From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20140717172910.GH93733@kib.kiev.ua> References: <1405545833.1312.84.camel@revolution.hippie.lan> <20140717004537.GE93733@kib.kiev.ua> <1405616990.1312.111.camel@revolution.hippie.lan> <20140717172910.GH93733@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Jul 2014 12:10:07 -0600 Message-ID: <1405620607.1312.122.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 18:10:11 -0000 On Thu, 2014-07-17 at 20:29 +0300, Konstantin Belousov wrote: > On Thu, Jul 17, 2014 at 11:09:50AM -0600, Ian Lepore wrote: > > On Thu, 2014-07-17 at 03:45 +0300, Konstantin Belousov wrote: > > > On Wed, Jul 16, 2014 at 03:23:53PM -0600, Ian Lepore wrote: > > > > I need to add an ARM-specific function to rtld-elf.so to help locate > > > > exception unwind info in shared objects. I'm confused about how to add > > > > the function to Symbol.map... do I have to add a 1.4 section because it > > > > was first added in FreeBSD 11, or does it go into an existing section > > > > because it doesn't introduce changes to an existing ABI? > > > > > > > > -- Ian > > > > > > > There is no sense in continuing iterating if the pc value falls into the > > > segment range, but segment does not have PF_X permission bit; there may > > > be at most one segment mapped at the given address. That said, the > > > _rtld_addr_phdr() is more suitable function to use for findexcb(), since > > > it provides you with the needed object directly, without iterating on > > > the previously loaded objects. > > > > > > > Oh, I didn't know about _rtld_addr_phdr(), I'll rewrite it using that to > > do the iteration part for me. > The _rtld_addr_phdr() does not iterate. If it did it job by calling > dl_iterate_phdr(3), it would be part of libc. > Are we talking about the same function? It looks to me like _rtld_addr_phdr() calls obj_from_addr(), which iterates like: for (obj = obj_list; obj != NULL; obj = obj->next) [ return this object if the addr is within it ] > > > > > Why do you need the __gnu_Unwind_Find_exidx() be the part of rtld ? > > > I do not see a reason for e.g. libc/arm not be a good home for the > > > function. We try to not extend the ABI of rtld unless there are > > > very strong reasons. The function implementation does not use any > > > internal rtld structures, only external interfaces. > > > > > > > There is a default version of this function which works only for > > statically linked apps in contrib/gcc/config/arm/unwind-arm.c, defined > > with __attribute__((weak)). For dynamically linked apps, a replacement > > version needs to override the weak-linkage default to find the exidx > > data in one of the loaded objects. The scheme is similar to the stuff > > in libc/gen/dlfcn.c. > Our rtld does not follow ELF standard. There is no requirement that > weak symbol has lower resolution priority than non-weak. Basically, > libc dlfcn.c relies on the bug. Eventually, this stuff should be only > compiled for the libc.a. > > > > > I did some looking around and Netbsd, Android, and Risc Os all > > implemented this in their dynamic loaders, so that seemed like the way > > to go. Android actually puts a function with this __gnu name in its > > libc, but all that function does is calls dl_unwind_find_exidx() which > > is implemented in their loader. > > > > I've just discovered that the arm unwind support code that will arrive > > as part of clang 3.5 appears to assume the Android way of things unless > > __LINUX__ is defined, so maybe it would be good to follow that model > > ourselves and add a dl_unwind_find_exidx() stub to libc/gen/dlfcn.c and > > name the new implementation in ld-elf to match. > I think that Android/__LINUX__ combination does the right thing, by > providing the symbol in libc. A libc implementation does not need any > additional service from rtld, except already existing _rtld_addr_phdr(). > The implementation (whether in libc or elsewhere) needs to behave differently depending on whether shared objects are involved or not. The mechanism other projects are using to achieve this is weak implementation for static linked, overridden by a dynamic implementation in ld-elf.so. If we don't use that mechanism, then what mechanism do we have for using either #ifdef in the code or .ifdef in a makefile to change the implementation based on building libc.a vs libc.so? > Also, I recomment you to look at the libc helper __elf_phdr_match_addr > from libc/gen/elf_utils.c, which, together with _rtld_addr_phdr(), > seemingly implements 70% of your function. > I don't see how __elf_phdr_match_addr helps at all. It appears to just return true/false to say whether an address falls within a shared object or not. _rtld_addr_phdr() will already give me the shared object that contains the address, then I still have to iterate the entries in the phdr to find the address and size of the exidx section. > That said, please do not put MD function in dlfcn.c, but into a new > file in libc/arm/gen/. > > > > > What is the supposed use of the function ? Are the consumers of it > > > only the system libraries, or is it planned that user binaries will > > > reference the symbol directly from their symbol table ? > > > > > If first, the place for the symbol is FBSDprivate_1.0 namespace. > > > If it must be used directly by binaries for which we provide ABI > > > stability guarantees, than FBSD_1.4 is the correct namespace to > > > put the symbol into, regardless of the shared object which would > > > provide it. > > > > > > > The problem I'm working on is making C++ exceptions work on ARM. The > > exception handling code in the C++ runtime support libraries needs this. > > It might also be needed by other code/tools that need to generate > > backtraces or otherwise use the unwind info. > > > > I guess I don't know how/where to draw the line between public and > > private libraries. If someone is using a version of gcc later than > > 4.2.1, the libraries that are part of that toolchain are going to > > reference this function name, that feels kind of public to me. > > I.e., it is provided so that third-party runtime libraries could use > the symbol to do the lookup of exception tables ? This indeed sounds > as the public interface, so it should go into FBSD_1.4. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 18 00:17:45 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 771D7F29 for ; Fri, 18 Jul 2014 00:17:45 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 347B22149 for ; Fri, 18 Jul 2014 00:17:44 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X7vrr-0000EI-Fr; Fri, 18 Jul 2014 00:17:43 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6I0HghC019491; Thu, 17 Jul 2014 18:17:42 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/TukSHOQwYtUFyfgdlCyhz X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [CFR] Adding a function to rtld-elf.so, how to handle Symbol.map? From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20140717172910.GH93733@kib.kiev.ua> References: <1405545833.1312.84.camel@revolution.hippie.lan> <20140717004537.GE93733@kib.kiev.ua> <1405616990.1312.111.camel@revolution.hippie.lan> <20140717172910.GH93733@kib.kiev.ua> Content-Type: multipart/mixed; boundary="=-9/8rZe+d9rK3teh1VWmm" Date: Thu, 17 Jul 2014 18:17:41 -0600 Message-ID: <1405642661.1312.135.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 00:17:45 -0000 --=-9/8rZe+d9rK3teh1VWmm Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, 2014-07-17 at 20:29 +0300, Konstantin Belousov wrote: > On Thu, Jul 17, 2014 at 11:09:50AM -0600, Ian Lepore wrote: > > On Thu, 2014-07-17 at 03:45 +0300, Konstantin Belousov wrote: > > > On Wed, Jul 16, 2014 at 03:23:53PM -0600, Ian Lepore wrote: > > [snip] > > I did some looking around and Netbsd, Android, and Risc Os all > > implemented this in their dynamic loaders, so that seemed like the way > > to go. Android actually puts a function with this __gnu name in its > > libc, but all that function does is calls dl_unwind_find_exidx() which > > is implemented in their loader. > > > > I've just discovered that the arm unwind support code that will arrive > > as part of clang 3.5 appears to assume the Android way of things unless > > __LINUX__ is defined, so maybe it would be good to follow that model > > ourselves and add a dl_unwind_find_exidx() stub to libc/gen/dlfcn.c and > > name the new implementation in ld-elf to match. > I think that Android/__LINUX__ combination does the right thing, by > providing the symbol in libc. A libc implementation does not need any > additional service from rtld, except already existing _rtld_addr_phdr(). > Android provides a stub of dl_unwind_find_exidx() in libdl and the shared-object implementation in the dynamic linker. What it puts in libc is the __gnu_Unwind_Find_exidx() symbol, which just calls through to the dl_unwind_find_exidx() implementation in the dynamic linker. That aside, I've reworked my code so it all lives in libc instead of rtld, as you suggested. It seems to work fine, and I guess I'm agnostic about whether we're exporting a new function from libc versus rtld. It seems a bit strange to me to have just one dl_something() function with its shared/dynamic implementation in libc, while all the other functions with dl-prefix names are implemented in rtld. But not so weird that it's a big deal. -- Ian --=-9/8rZe+d9rK3teh1VWmm Content-Disposition: inline; filename="find_exidx3.diff" Content-Type: text/x-patch; name="find_exidx3.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit diff -r 63a383d5fd3e lib/libc/arm/Symbol.map --- lib/libc/arm/Symbol.map Thu May 01 08:14:39 2014 -0600 +++ lib/libc/arm/Symbol.map Thu Jul 17 17:49:52 2014 -0600 @@ -37,6 +37,11 @@ FBSD_1.3 { __flt_rounds; }; +FBSD_1.4 { + __gnu_Unwind_Find_exidx; + dl_unwind_find_exidx; +}; + FBSDprivate_1.0 { /* PSEUDO syscalls */ __sys_getlogin; diff -r 63a383d5fd3e lib/libc/arm/aeabi/Makefile.inc --- lib/libc/arm/aeabi/Makefile.inc Thu May 01 08:14:39 2014 -0600 +++ lib/libc/arm/aeabi/Makefile.inc Thu Jul 17 17:49:52 2014 -0600 @@ -3,7 +3,8 @@ .PATH: ${LIBC_SRCTOP}/arm/aeabi SRCS+= aeabi_atexit.c \ - aeabi_unwind_cpp.c + aeabi_unwind_cpp.c \ + aeabi_unwind_exidx.c .if ${MACHINE_ARCH} != "armv6hf" SRCS+= aeabi_double.c \ aeabi_float.c diff -r 63a383d5fd3e lib/libc/arm/aeabi/aeabi_unwind_exidx.c --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ lib/libc/arm/aeabi/aeabi_unwind_exidx.c Thu Jul 17 17:49:52 2014 -0600 @@ -0,0 +1,104 @@ +/*- + * Copyright (c) 2014 Ian Lepore + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include + +/* + * ARM EABI unwind helper. + * + * This finds the exidx section address and size associated with a given code + * address. There are separate implementations for static and dynamic code. + * + * GCC expects this function to exist as __gnu_Unwind_Find_exidx(), clang and + * BSD tools expect it to be dl_unwind_find_exidx(). Both have the same API, so + * we set up an alias for GCC. + */ +__strong_reference(dl_unwind_find_exidx, __gnu_Unwind_Find_exidx); + +/* + * Each entry in the exidx section is a pair of 32-bit words. We don't + * interpret the contents of the entries here; this typedef is just a local + * convenience for using sizeof() and doing pointer math. + */ +typedef struct exidx_entry { + uint32_t data[2]; +} exidx_entry; + +#ifdef __PIC__ + +/* + * Unwind helper for dynamically linked code. + * + * This finds the shared object that contains the given address, and returns the + * address of the exidx section in that shared object along with the number of + * entries in that section, or NULL if it wasn't found. + */ +void * +dl_unwind_find_exidx(const void *pc, int *pcount) +{ + const Elf_Phdr *hdr; + struct dl_phdr_info info; + int i; + + if (_rtld_addr_phdr(pc, &info)) { + hdr = info.dlpi_phdr; + for (i = 0; i < info.dlpi_phnum; i++, hdr++) { + if (hdr->p_type == PT_ARM_EXIDX) { + *pcount = hdr->p_memsz / (sizeof(exidx_entry)); + return ((void *)(info.dlpi_addr + hdr->p_vaddr)); + } + } + } + return (NULL); +} + +#else /* !__PIC__ */ + +/* + * Unwind helper for statically linked code. + * + * In a statically linked program, the linker populates a pair of symbols with + * the addresses of the start and end of the exidx table, so returning the + * address and count of elements is pretty straighforward. + */ +void * +dl_unwind_find_exidx(const void *pc, int *pcount) +{ + extern struct exidx_entry __exidx_start; + extern struct exidx_entry __exidx_end; + + *pcount = (int)(&__exidx_end - &__exidx_start); + return (&__exidx_start); +} + +#endif /* __PIC__ */ + diff -r 63a383d5fd3e sys/arm/include/elf.h --- sys/arm/include/elf.h Thu May 01 08:14:39 2014 -0600 +++ sys/arm/include/elf.h Thu Jul 17 17:49:52 2014 -0600 @@ -55,6 +55,9 @@ typedef struct { /* Auxiliary vec #define ELF_MACHINE_OK(x) ((x) == EM_ARM) +/* Unwind info section type */ +#define PT_ARM_EXIDX (PT_LOPROC + 1) + /* * Relocation types. */ diff -r 63a383d5fd3e sys/sys/link_elf.h --- sys/sys/link_elf.h Thu May 01 08:14:39 2014 -0600 +++ sys/sys/link_elf.h Thu Jul 17 17:49:52 2014 -0600 @@ -95,6 +95,10 @@ extern int dl_iterate_phdr(__dl_iterate_ int _rtld_addr_phdr(const void *, struct dl_phdr_info *); int _rtld_get_stack_prot(void); +#ifdef __ARM_EABI__ +void * dl_unwind_find_exidx(const void *, int *); +#endif + __END_DECLS #endif /* _SYS_LINK_ELF_H_ */ --=-9/8rZe+d9rK3teh1VWmm-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 18 08:15:01 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBC0C3D6; Fri, 18 Jul 2014 08:15:01 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5358D27E1; Fri, 18 Jul 2014 08:15:01 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s6I8Etks083439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jul 2014 11:14:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s6I8Etks083439 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s6I8Etn2083438; Fri, 18 Jul 2014 11:14:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 18 Jul 2014 11:14:55 +0300 From: Konstantin Belousov To: Ian Lepore Subject: Re: [CFR] Adding a function to rtld-elf.so, how to handle Symbol.map? Message-ID: <20140718081455.GI93733@kib.kiev.ua> References: <1405545833.1312.84.camel@revolution.hippie.lan> <20140717004537.GE93733@kib.kiev.ua> <1405616990.1312.111.camel@revolution.hippie.lan> <20140717172910.GH93733@kib.kiev.ua> <1405642661.1312.135.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/sv6gJA63ZcCAX3m" Content-Disposition: inline In-Reply-To: <1405642661.1312.135.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 08:15:02 -0000 --/sv6gJA63ZcCAX3m Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 17, 2014 at 06:17:41PM -0600, Ian Lepore wrote: > On Thu, 2014-07-17 at 20:29 +0300, Konstantin Belousov wrote: > > On Thu, Jul 17, 2014 at 11:09:50AM -0600, Ian Lepore wrote: > > > On Thu, 2014-07-17 at 03:45 +0300, Konstantin Belousov wrote: > > > > On Wed, Jul 16, 2014 at 03:23:53PM -0600, Ian Lepore wrote: > > > [snip] >=20 > > > I did some looking around and Netbsd, Android, and Risc Os all > > > implemented this in their dynamic loaders, so that seemed like the way > > > to go. Android actually puts a function with this __gnu name in its > > > libc, but all that function does is calls dl_unwind_find_exidx() which > > > is implemented in their loader. > > >=20 > > > I've just discovered that the arm unwind support code that will arrive > > > as part of clang 3.5 appears to assume the Android way of things unle= ss > > > __LINUX__ is defined, so maybe it would be good to follow that model > > > ourselves and add a dl_unwind_find_exidx() stub to libc/gen/dlfcn.c a= nd > > > name the new implementation in ld-elf to match. > > I think that Android/__LINUX__ combination does the right thing, by > > providing the symbol in libc. A libc implementation does not need any > > additional service from rtld, except already existing _rtld_addr_phdr(). > >=20 >=20 > Android provides a stub of dl_unwind_find_exidx() in libdl and the > shared-object implementation in the dynamic linker. What it puts in > libc is the __gnu_Unwind_Find_exidx() symbol, which just calls through > to the dl_unwind_find_exidx() implementation in the dynamic linker. >=20 > That aside, I've reworked my code so it all lives in libc instead of > rtld, as you suggested. It seems to work fine, and I guess I'm agnostic > about whether we're exporting a new function from libc versus rtld. It > seems a bit strange to me to have just one dl_something() function with > its shared/dynamic implementation in libc, while all the other functions > with dl-prefix names are implemented in rtld. But not so weird that > it's a big deal. The new patch is fine with me. =20 Could you, please, comment why did you decided to export the dl_unwind_find_exidx alias ? It was absent in the original patch, and from your description, it seems to be an implementation detail on Linux. --/sv6gJA63ZcCAX3m Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTyNd/AAoJEJDCuSvBvK1BY3YP/i+0rHyXtv2s6+WUIZIAq7Sx qt5EhabJT+e934pErTLH4BZPizbRXBjGM7FI8/cr43KsiiM3Dq6p2Y2zupOMk5l8 DrX76pqEdzCB7Nr7NydQuglBw+OAXatJBiN51VMdWC+uO04Gi1+Ne8581fceAG82 rQ79PcXtTmmCrtQQaJvQFuBUKTV3qdc5pdn0Hoso11+OPDWSs0ajmqlgFSgS2X5x 15s8x4uV7qUjWVbD8ksdxs49dPBr8x7wUfRnakBWNv71Gna5isRCSyJQsWjDPCCJ zKTVxq95fubyEe2LOX72m7xlCqpXB8/Cidy2T+fP/ziFkQvB+pH4xzQGyuC87Qnx h9ZLaEbHl/n+JToXgyEk10NCVcd8vDL3FktS6p9yNrRlleA7RB33evdgjyUgmjXG vNApBeridTmwb3E1UhC+SkOKcOwP+6j7Y9+DkHhFelDSeHGCTcMHyIdAtwY3METf ItBpKH+agIk+8+KI2UiSUjgySFyF4SpnPYTo+F8ZTKwrLxKtt9t+HzIaNwr73FN4 Z4EXqyz23TMv1ije7TU397DAyW4n6eYWm8dIR9DhqJ4zdx2X586Q23YhE57qCO1q D+nCrcrrX8dDw51YK1P6KH3ILdDhn9LkpO3cZsNtY71mgLxahF7qPOTIBBrnXwBs QKro600NBsAy/s4/IS1d =7OX1 -----END PGP SIGNATURE----- --/sv6gJA63ZcCAX3m-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 18 13:24:08 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83A1E258 for ; Fri, 18 Jul 2014 13:24:08 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5466B2392 for ; Fri, 18 Jul 2014 13:24:08 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X888m-000OWk-U0; Fri, 18 Jul 2014 13:24:01 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6IDNx7V022055; Fri, 18 Jul 2014 07:23:59 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/5dvoaCeVd8dwgubJDEk10 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [CFR] Adding a function to rtld-elf.so, how to handle Symbol.map? From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20140718081455.GI93733@kib.kiev.ua> References: <1405545833.1312.84.camel@revolution.hippie.lan> <20140717004537.GE93733@kib.kiev.ua> <1405616990.1312.111.camel@revolution.hippie.lan> <20140717172910.GH93733@kib.kiev.ua> <1405642661.1312.135.camel@revolution.hippie.lan> <20140718081455.GI93733@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Jul 2014 07:23:59 -0600 Message-ID: <1405689839.1312.148.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 13:24:08 -0000 On Fri, 2014-07-18 at 11:14 +0300, Konstantin Belousov wrote: > On Thu, Jul 17, 2014 at 06:17:41PM -0600, Ian Lepore wrote: > > On Thu, 2014-07-17 at 20:29 +0300, Konstantin Belousov wrote: > > > On Thu, Jul 17, 2014 at 11:09:50AM -0600, Ian Lepore wrote: > > > > On Thu, 2014-07-17 at 03:45 +0300, Konstantin Belousov wrote: > > > > > On Wed, Jul 16, 2014 at 03:23:53PM -0600, Ian Lepore wrote: > > > > [snip] > > > > > > I did some looking around and Netbsd, Android, and Risc Os all > > > > implemented this in their dynamic loaders, so that seemed like the way > > > > to go. Android actually puts a function with this __gnu name in its > > > > libc, but all that function does is calls dl_unwind_find_exidx() which > > > > is implemented in their loader. > > > > > > > > I've just discovered that the arm unwind support code that will arrive > > > > as part of clang 3.5 appears to assume the Android way of things unless > > > > __LINUX__ is defined, so maybe it would be good to follow that model > > > > ourselves and add a dl_unwind_find_exidx() stub to libc/gen/dlfcn.c and > > > > name the new implementation in ld-elf to match. > > > I think that Android/__LINUX__ combination does the right thing, by > > > providing the symbol in libc. A libc implementation does not need any > > > additional service from rtld, except already existing _rtld_addr_phdr(). > > > > > > > Android provides a stub of dl_unwind_find_exidx() in libdl and the > > shared-object implementation in the dynamic linker. What it puts in > > libc is the __gnu_Unwind_Find_exidx() symbol, which just calls through > > to the dl_unwind_find_exidx() implementation in the dynamic linker. > > > > That aside, I've reworked my code so it all lives in libc instead of > > rtld, as you suggested. It seems to work fine, and I guess I'm agnostic > > about whether we're exporting a new function from libc versus rtld. It > > seems a bit strange to me to have just one dl_something() function with > > its shared/dynamic implementation in libc, while all the other functions > > with dl-prefix names are implemented in rtld. But not so weird that > > it's a big deal. > The new patch is fine with me. > > Could you, please, comment why did you decided to export the > dl_unwind_find_exidx alias ? It was absent in the original patch, > and from your description, it seems to be an implementation detail > on Linux. I think you might have misunderstood what I said earlier. According to comments in some clang 3.5 sources I saw, the clang project considers dl_unwind_find_exidx() to be "the BSD interface" for finding the exidx data. They fall back to the gnu name only when clang is compiled with __LINUX__ defined. By providing the functionality with this name, clang 3.5 will just work right on freebsd without needing to be modified to also use the gnu name when __FreeBSD__ is defined. Android and Netbsd provide dl_unwind_find_exidx(); I haven't checked other BSDs. It certainly is a better name for an interface shared by different toolchains than __gnu_Unwind_Find_exidx(), although we do need to also provide that symbol for anyone using gcc. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 18 13:36:31 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00758AF0; Fri, 18 Jul 2014 13:36:30 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9344424F7; Fri, 18 Jul 2014 13:36:30 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s6IDaP6N058380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jul 2014 16:36:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s6IDaP6N058380 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s6IDaPP0058379; Fri, 18 Jul 2014 16:36:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 18 Jul 2014 16:36:25 +0300 From: Konstantin Belousov To: Ian Lepore Subject: Re: [CFR] Adding a function to rtld-elf.so, how to handle Symbol.map? Message-ID: <20140718133625.GL93733@kib.kiev.ua> References: <1405545833.1312.84.camel@revolution.hippie.lan> <20140717004537.GE93733@kib.kiev.ua> <1405616990.1312.111.camel@revolution.hippie.lan> <20140717172910.GH93733@kib.kiev.ua> <1405642661.1312.135.camel@revolution.hippie.lan> <20140718081455.GI93733@kib.kiev.ua> <1405689839.1312.148.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B+Izp8cWEYSQgag+" Content-Disposition: inline In-Reply-To: <1405689839.1312.148.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 13:36:31 -0000 --B+Izp8cWEYSQgag+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 18, 2014 at 07:23:59AM -0600, Ian Lepore wrote: > On Fri, 2014-07-18 at 11:14 +0300, Konstantin Belousov wrote: > > On Thu, Jul 17, 2014 at 06:17:41PM -0600, Ian Lepore wrote: > > > On Thu, 2014-07-17 at 20:29 +0300, Konstantin Belousov wrote: > > > > On Thu, Jul 17, 2014 at 11:09:50AM -0600, Ian Lepore wrote: > > > > > On Thu, 2014-07-17 at 03:45 +0300, Konstantin Belousov wrote: > > > > > > On Wed, Jul 16, 2014 at 03:23:53PM -0600, Ian Lepore wrote: > > > > > [snip] > > >=20 > > > > > I did some looking around and Netbsd, Android, and Risc Os all > > > > > implemented this in their dynamic loaders, so that seemed like th= e way > > > > > to go. Android actually puts a function with this __gnu name in = its > > > > > libc, but all that function does is calls dl_unwind_find_exidx() = which > > > > > is implemented in their loader. > > > > >=20 > > > > > I've just discovered that the arm unwind support code that will a= rrive > > > > > as part of clang 3.5 appears to assume the Android way of things = unless > > > > > __LINUX__ is defined, so maybe it would be good to follow that mo= del > > > > > ourselves and add a dl_unwind_find_exidx() stub to libc/gen/dlfcn= =2Ec and > > > > > name the new implementation in ld-elf to match. > > > > I think that Android/__LINUX__ combination does the right thing, by > > > > providing the symbol in libc. A libc implementation does not need a= ny > > > > additional service from rtld, except already existing _rtld_addr_ph= dr(). > > > >=20 > > >=20 > > > Android provides a stub of dl_unwind_find_exidx() in libdl and the > > > shared-object implementation in the dynamic linker. What it puts in > > > libc is the __gnu_Unwind_Find_exidx() symbol, which just calls through > > > to the dl_unwind_find_exidx() implementation in the dynamic linker. > > >=20 > > > That aside, I've reworked my code so it all lives in libc instead of > > > rtld, as you suggested. It seems to work fine, and I guess I'm agnos= tic > > > about whether we're exporting a new function from libc versus rtld. = It > > > seems a bit strange to me to have just one dl_something() function wi= th > > > its shared/dynamic implementation in libc, while all the other functi= ons > > > with dl-prefix names are implemented in rtld. But not so weird that > > > it's a big deal. > > The new patch is fine with me. =20 > >=20 > > Could you, please, comment why did you decided to export the > > dl_unwind_find_exidx alias ? It was absent in the original patch, > > and from your description, it seems to be an implementation detail > > on Linux. >=20 > I think you might have misunderstood what I said earlier. According to > comments in some clang 3.5 sources I saw, the clang project considers > dl_unwind_find_exidx() to be "the BSD interface" for finding the exidx > data. They fall back to the gnu name only when clang is compiled with > __LINUX__ defined. By providing the functionality with this name, clang > 3.5 will just work right on freebsd without needing to be modified to > also use the gnu name when __FreeBSD__ is defined. >=20 > Android and Netbsd provide dl_unwind_find_exidx(); I haven't checked > other BSDs. It certainly is a better name for an interface shared by > different toolchains than __gnu_Unwind_Find_exidx(), although we do need > to also provide that symbol for anyone using gcc. Yes, I indeed misunderstood your description, thank you for the clarificati= on. I.e. clang on Linux and gcc use __gnu_Unwind_Find_exidx(), while (future) clang on non-Linuxes uses dl_unwind_find_exidx() ? And there is no ABI statement on the symbol, right ? --B+Izp8cWEYSQgag+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTySLYAAoJEJDCuSvBvK1BpEkP/jcFWhlQVQuAiRAmPQrt/atB HXwkgOwyeNz+qPCfC6KylSVcYL7o5dtJBz6MeZjIBjLmzDX1K6IExC2wCWrcZ8mn Gsx7aN5j6dPEmSd7LMLOeqA3l/O9+oDNdH7GU0AewnMdPFxPbV4OMOyEAMxgQtwi c2sV/H5wKmbGM1yenAgVlkx5rrYOJ3aCg78fvTBqSCzBzbDjgDCJeoPuH0+Q0Yn/ XpWsHbxXKykrdmESoEE/WeWLSgKBObxgVCoelsPWjP/1wsdLjMwkPmsJACBrkc6P +dthlxW8xXTRptq2GRP6Fzw/wtiXY0HuKAZ1WtVX6BNq4DjbrsxYG7H0tg5qdqB3 WLk6IIUUrvH7kl5J8X0vz6k+7WTTLQNP0NJA3qsAS0WuhUf9tYvUKSFamPqOueyE WraA9/5xu2JwqM+wtMUCrh12mJNAPdyXgEgjpoR/0q2eCo4hZhKI5HKgEUSzwqvT RwSJ9zY9DFliL8cBUx29GZ31NmkDqYuk8qD12FAdFHpACn05iArpfCxMF2BejefU DJayiYLK/6khGSRe/tUTQwtmnE1HIpr2I8UkrP2hwhDnsqTJ5NLxZDbvwNzZJH/h w5ouUoxKAXZktCAkYdDw/gf6DwJkqXY7J8dyT0C8ooZtRemDcVsSaaMgnQu6u6Wb HEZLRiA6j/U2rxlmRHD0 =el5q -----END PGP SIGNATURE----- --B+Izp8cWEYSQgag+-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 18 15:22:18 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82E30CD4 for ; Fri, 18 Jul 2014 15:22:18 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40C702F41 for ; Fri, 18 Jul 2014 15:22:17 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X89zE-000I1a-Dj; Fri, 18 Jul 2014 15:22:16 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6IFMF7n023418; Fri, 18 Jul 2014 09:22:15 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+AL33QnZgnum21yJTdX4pc X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [CFR] Adding a function to rtld-elf.so, how to handle Symbol.map? From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20140718133625.GL93733@kib.kiev.ua> References: <1405545833.1312.84.camel@revolution.hippie.lan> <20140717004537.GE93733@kib.kiev.ua> <1405616990.1312.111.camel@revolution.hippie.lan> <20140717172910.GH93733@kib.kiev.ua> <1405642661.1312.135.camel@revolution.hippie.lan> <20140718081455.GI93733@kib.kiev.ua> <1405689839.1312.148.camel@revolution.hippie.lan> <20140718133625.GL93733@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Jul 2014 07:49:14 -0600 Message-ID: <1405691354.1312.152.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 15:22:18 -0000 On Fri, 2014-07-18 at 16:36 +0300, Konstantin Belousov wrote: > On Fri, Jul 18, 2014 at 07:23:59AM -0600, Ian Lepore wrote: > > On Fri, 2014-07-18 at 11:14 +0300, Konstantin Belousov wrote: > > > On Thu, Jul 17, 2014 at 06:17:41PM -0600, Ian Lepore wrote: > > > > On Thu, 2014-07-17 at 20:29 +0300, Konstantin Belousov wrote: > > > > > On Thu, Jul 17, 2014 at 11:09:50AM -0600, Ian Lepore wrote: > > > > > > On Thu, 2014-07-17 at 03:45 +0300, Konstantin Belousov wrote: > > > > > > > On Wed, Jul 16, 2014 at 03:23:53PM -0600, Ian Lepore wrote: > > > > > > [snip] > > > > > > > > > > I did some looking around and Netbsd, Android, and Risc Os all > > > > > > implemented this in their dynamic loaders, so that seemed like the way > > > > > > to go. Android actually puts a function with this __gnu name in its > > > > > > libc, but all that function does is calls dl_unwind_find_exidx() which > > > > > > is implemented in their loader. > > > > > > > > > > > > I've just discovered that the arm unwind support code that will arrive > > > > > > as part of clang 3.5 appears to assume the Android way of things unless > > > > > > __LINUX__ is defined, so maybe it would be good to follow that model > > > > > > ourselves and add a dl_unwind_find_exidx() stub to libc/gen/dlfcn.c and > > > > > > name the new implementation in ld-elf to match. > > > > > I think that Android/__LINUX__ combination does the right thing, by > > > > > providing the symbol in libc. A libc implementation does not need any > > > > > additional service from rtld, except already existing _rtld_addr_phdr(). > > > > > > > > > > > > > Android provides a stub of dl_unwind_find_exidx() in libdl and the > > > > shared-object implementation in the dynamic linker. What it puts in > > > > libc is the __gnu_Unwind_Find_exidx() symbol, which just calls through > > > > to the dl_unwind_find_exidx() implementation in the dynamic linker. > > > > > > > > That aside, I've reworked my code so it all lives in libc instead of > > > > rtld, as you suggested. It seems to work fine, and I guess I'm agnostic > > > > about whether we're exporting a new function from libc versus rtld. It > > > > seems a bit strange to me to have just one dl_something() function with > > > > its shared/dynamic implementation in libc, while all the other functions > > > > with dl-prefix names are implemented in rtld. But not so weird that > > > > it's a big deal. > > > The new patch is fine with me. > > > > > > Could you, please, comment why did you decided to export the > > > dl_unwind_find_exidx alias ? It was absent in the original patch, > > > and from your description, it seems to be an implementation detail > > > on Linux. > > > > I think you might have misunderstood what I said earlier. According to > > comments in some clang 3.5 sources I saw, the clang project considers > > dl_unwind_find_exidx() to be "the BSD interface" for finding the exidx > > data. They fall back to the gnu name only when clang is compiled with > > __LINUX__ defined. By providing the functionality with this name, clang > > 3.5 will just work right on freebsd without needing to be modified to > > also use the gnu name when __FreeBSD__ is defined. > > > > Android and Netbsd provide dl_unwind_find_exidx(); I haven't checked > > other BSDs. It certainly is a better name for an interface shared by > > different toolchains than __gnu_Unwind_Find_exidx(), although we do need > > to also provide that symbol for anyone using gcc. > > Yes, I indeed misunderstood your description, thank you for the clarification. > I.e. clang on Linux and gcc use __gnu_Unwind_Find_exidx(), while (future) > clang on non-Linuxes uses dl_unwind_find_exidx() ? And there is no > ABI statement on the symbol, right ? Right, except I don't understand what you are asking in your last sentence. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 18 15:57:19 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E800DCFA; Fri, 18 Jul 2014 15:57:18 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88DF122C2; Fri, 18 Jul 2014 15:57:18 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s6IFvCML090684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jul 2014 18:57:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s6IFvCML090684 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s6IFvCAU090683; Fri, 18 Jul 2014 18:57:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 18 Jul 2014 18:57:12 +0300 From: Konstantin Belousov To: Ian Lepore Subject: Re: [CFR] Adding a function to rtld-elf.so, how to handle Symbol.map? Message-ID: <20140718155712.GM93733@kib.kiev.ua> References: <1405545833.1312.84.camel@revolution.hippie.lan> <20140717004537.GE93733@kib.kiev.ua> <1405616990.1312.111.camel@revolution.hippie.lan> <20140717172910.GH93733@kib.kiev.ua> <1405642661.1312.135.camel@revolution.hippie.lan> <20140718081455.GI93733@kib.kiev.ua> <1405689839.1312.148.camel@revolution.hippie.lan> <20140718133625.GL93733@kib.kiev.ua> <1405691354.1312.152.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vIs3Povh1jkh1Gsq" Content-Disposition: inline In-Reply-To: <1405691354.1312.152.camel@revolution.hippie.lan> User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 15:57:19 -0000 --vIs3Povh1jkh1Gsq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 18, 2014 at 07:49:14AM -0600, Ian Lepore wrote: > On Fri, 2014-07-18 at 16:36 +0300, Konstantin Belousov wrote: > > On Fri, Jul 18, 2014 at 07:23:59AM -0600, Ian Lepore wrote: > > > On Fri, 2014-07-18 at 11:14 +0300, Konstantin Belousov wrote: > > > > On Thu, Jul 17, 2014 at 06:17:41PM -0600, Ian Lepore wrote: > > > > > On Thu, 2014-07-17 at 20:29 +0300, Konstantin Belousov wrote: > > > > > > On Thu, Jul 17, 2014 at 11:09:50AM -0600, Ian Lepore wrote: > > > > > > > On Thu, 2014-07-17 at 03:45 +0300, Konstantin Belousov wrote: > > > > > > > > On Wed, Jul 16, 2014 at 03:23:53PM -0600, Ian Lepore wrote: > > > > > > > [snip] > > > > >=20 > > > > > > > I did some looking around and Netbsd, Android, and Risc Os all > > > > > > > implemented this in their dynamic loaders, so that seemed lik= e the way > > > > > > > to go. Android actually puts a function with this __gnu name= in its > > > > > > > libc, but all that function does is calls dl_unwind_find_exid= x() which > > > > > > > is implemented in their loader. > > > > > > >=20 > > > > > > > I've just discovered that the arm unwind support code that wi= ll arrive > > > > > > > as part of clang 3.5 appears to assume the Android way of thi= ngs unless > > > > > > > __LINUX__ is defined, so maybe it would be good to follow tha= t model > > > > > > > ourselves and add a dl_unwind_find_exidx() stub to libc/gen/d= lfcn.c and > > > > > > > name the new implementation in ld-elf to match. > > > > > > I think that Android/__LINUX__ combination does the right thing= , by > > > > > > providing the symbol in libc. A libc implementation does not ne= ed any > > > > > > additional service from rtld, except already existing _rtld_add= r_phdr(). > > > > > >=20 > > > > >=20 > > > > > Android provides a stub of dl_unwind_find_exidx() in libdl and the > > > > > shared-object implementation in the dynamic linker. What it puts= in > > > > > libc is the __gnu_Unwind_Find_exidx() symbol, which just calls th= rough > > > > > to the dl_unwind_find_exidx() implementation in the dynamic linke= r. > > > > >=20 > > > > > That aside, I've reworked my code so it all lives in libc instead= of > > > > > rtld, as you suggested. It seems to work fine, and I guess I'm a= gnostic > > > > > about whether we're exporting a new function from libc versus rtl= d. It > > > > > seems a bit strange to me to have just one dl_something() functio= n with > > > > > its shared/dynamic implementation in libc, while all the other fu= nctions > > > > > with dl-prefix names are implemented in rtld. But not so weird t= hat > > > > > it's a big deal. > > > > The new patch is fine with me. =20 > > > >=20 > > > > Could you, please, comment why did you decided to export the > > > > dl_unwind_find_exidx alias ? It was absent in the original patch, > > > > and from your description, it seems to be an implementation detail > > > > on Linux. > > >=20 > > > I think you might have misunderstood what I said earlier. According = to > > > comments in some clang 3.5 sources I saw, the clang project considers > > > dl_unwind_find_exidx() to be "the BSD interface" for finding the exidx > > > data. They fall back to the gnu name only when clang is compiled with > > > __LINUX__ defined. By providing the functionality with this name, cl= ang > > > 3.5 will just work right on freebsd without needing to be modified to > > > also use the gnu name when __FreeBSD__ is defined. > > >=20 > > > Android and Netbsd provide dl_unwind_find_exidx(); I haven't checked > > > other BSDs. It certainly is a better name for an interface shared by > > > different toolchains than __gnu_Unwind_Find_exidx(), although we do n= eed > > > to also provide that symbol for anyone using gcc. > >=20 > > Yes, I indeed misunderstood your description, thank you for the clarifi= cation. > > I.e. clang on Linux and gcc use __gnu_Unwind_Find_exidx(), while (futur= e) > > clang on non-Linuxes uses dl_unwind_find_exidx() ? And there is no > > ABI statement on the symbol, right ? >=20 > Right, except I don't understand what you are asking in your last > sentence. I ask, does ABI document requires the presence of the function ? Does the spec defines interface for the function ? --vIs3Povh1jkh1Gsq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTyUPYAAoJEJDCuSvBvK1BKeMP/iDTVkpSIwPOusYP1VFs8rn/ M3LW3xcGwPt5PtaZ4Jt6EZM38sYvVFdvhyXAh+i52hjE9qRTcu4p65mgHN8f1HPY VXXe6cb/XWN7idExnjUcIOZ+PlyLn70pZHPFvMuSUeRxX+Czr0rL5LJrQhOE/cpi MlAh1C156YdePLHn2ZE589oTF9XU1xhgeaImX2iNlpl5KnZpq0+o8CA573SYdi/E 7SpZ24ZXEZcPrWTSizSXpMa32Qk2p9RoQZw/sOK9VFF0xql9sXg28NcW7UEujUAx b1JasBDbvYWP9PZsRMo6Qjo/l1fBEGE0VymGS3SE5+rZQkOV4g0ltbuoCbJb4iZd lPha83Z6WfEkm2tW1YB+9e+sU2RMouKtq+UtU8GK/PRUDEJp2IQ1H9vI1sK8cpGo fVFet40qVNA1oGOkUJDPK2muAjwHoTEg1WN2P+l5qQkseYtqGySJSs1VWB+YS3LS Q8E0fSd2J/zos4xkEPgdvK38SiBHUv55PqRK1/CdOpodwPRs2Pp/FXYmarIvEtaL u16LXaj687fygsddVTPLX7O90cLKZXwZA8BmTux8YpTYKK40qS17XQBCRz6pvh5D vhv6YcxzQrd8mnwTRh/U49fR2QRjc176lPONYiRpvYm13yBjrKuSRahVdxnTafYR x1x2SDkwuPnDkxBrQaUv =2zso -----END PGP SIGNATURE----- --vIs3Povh1jkh1Gsq-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 18 16:21:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A76D70F for ; Fri, 18 Jul 2014 16:21:24 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ACA5224D9 for ; Fri, 18 Jul 2014 16:21:23 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id m15so3673584wgh.27 for ; Fri, 18 Jul 2014 09:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=SZzQRmbsaRl+u79C/ZN+IwAxrN2k7U1GH3XFQIN8qVk=; b=ZIs+Pw4RVtcHOk2XF8Ag4J0jtJdzNPtfP6n4mOE9G6W+HCC5un0SCZjCuKGKG5eBVQ dQ2A6pJ/mhX0c/P6VhG9wJEBXkzgTshZOy3VNIEjr/3h/cOegi872ZWDDmQBemPiHsfI C9dNaOfx1pLtnGl+QaT06IxqDHo7EQdfIxfTwAYNiEBkkp+DBFRvsoOU9HRX3B1uz9+T HSISZIBAKiAGAWkpKExncbUUulK2vxGqHhqDZLiCeQg1lJkrZoq9av9J7oWpUEOdyzS5 Rq3DqCElkNPWM6LV0xoQ3LtuQEWQoX3SwJ9f7ci10fd096usJo8ZD7DUWOc/pdUxLCMu JPWg== X-Received: by 10.180.80.225 with SMTP id u1mr7332662wix.69.1405700481947; Fri, 18 Jul 2014 09:21:21 -0700 (PDT) Received: from [192.168.178.121] (p5B36FDC5.dip0.t-ipconnect.de. [91.54.253.197]) by mx.google.com with ESMTPSA id eo4sm8283658wid.4.2014.07.18.09.21.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jul 2014 09:21:21 -0700 (PDT) Message-ID: <53C9497E.9020001@gmail.com> Date: Fri, 18 Jul 2014 18:21:18 +0200 From: =?ISO-8859-1?Q?Jan_Kokem=FCller?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Fixing fork detection of arc4random by implementing INHERIT_ZERO for minherit? Content-Type: multipart/mixed; boundary="------------090701060408080708060506" X-Mailman-Approved-At: Fri, 18 Jul 2014 16:40:25 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 16:21:24 -0000 This is a multi-part message in MIME format. --------------090701060408080708060506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, the issue mentioned at https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux also affects FreeBSDs arc4random implementation as its fork detection relies on changing pids only. Under FreeBSD, LibreSSL uses arc4random directly, and relies on it to be 100% fork safe. They don't provide a way to stir the RNG manually. I've brought this up with the LibreSSL developers, who think it's a bug in the OS (https://github.com/libressl-portable/portable/issues/17). I've tried to implement INHERIT_ZERO for minherit to make arc4random fork safe (patches attached). It seems to work fine so far, but I'm really no expert on FreeBSDs VM system. Also, the arc4random functions should probably be updated to use something more secure like ChaCha20 instead of RC4 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=182610). Cheers, Jan --------------090701060408080708060506 Content-Type: text/x-patch; name="minherit-inherit-zero.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="minherit-inherit-zero.patch" diff --git a/sys/sys/mman.h b/sys/sys/mman.h index e89bee3..e3cb967 100644 --- a/sys/sys/mman.h +++ b/sys/sys/mman.h @@ -43,6 +43,7 @@ #define INHERIT_SHARE 0 #define INHERIT_COPY 1 #define INHERIT_NONE 2 +#define INHERIT_ZERO 3 #endif /* diff --git a/sys/vm/vm.h b/sys/vm/vm.h index d87495d..0eb7568 100644 --- a/sys/vm/vm.h +++ b/sys/vm/vm.h @@ -68,6 +68,7 @@ typedef char vm_inherit_t; /* inheritance codes */ #define VM_INHERIT_SHARE ((vm_inherit_t) 0) #define VM_INHERIT_COPY ((vm_inherit_t) 1) #define VM_INHERIT_NONE ((vm_inherit_t) 2) +#define VM_INHERIT_ZERO ((vm_inherit_t) 3) #define VM_INHERIT_DEFAULT VM_INHERIT_COPY typedef u_char vm_prot_t; /* protection codes */ diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index 0713af8..a8c86ef 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -2229,6 +2229,7 @@ vm_map_inherit(vm_map_t map, vm_offset_t start, vm_offset_t end, case VM_INHERIT_NONE: case VM_INHERIT_COPY: case VM_INHERIT_SHARE: + case VM_INHERIT_ZERO: break; default: return (KERN_INVALID_ARGUMENT); @@ -3324,6 +3325,7 @@ vmspace_fork(struct vmspace *vm1, vm_ooffset_t *fork_charge) break; case VM_INHERIT_COPY: + case VM_INHERIT_ZERO: /* * Clone the entry and link into the map. */ @@ -3341,8 +3343,10 @@ vmspace_fork(struct vmspace *vm1, vm_ooffset_t *fork_charge) vm_map_entry_link(new_map, new_map->header.prev, new_entry); vmspace_map_entry_forked(vm1, vm2, new_entry); - vm_map_copy_entry(old_map, new_map, old_entry, - new_entry, fork_charge); + if (old_entry->inheritance == VM_INHERIT_COPY) { + vm_map_copy_entry(old_map, new_map, old_entry, + new_entry, fork_charge); + } break; } old_entry = old_entry->next; --------------090701060408080708060506 Content-Type: text/x-patch; name="arc4random-fork-safety-POC.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="arc4random-fork-safety-POC.patch" diff --git a/lib/libc/gen/arc4random.c b/lib/libc/gen/arc4random.c index 59e410b..8dab016 100644 --- a/lib/libc/gen/arc4random.c +++ b/lib/libc/gen/arc4random.c @@ -38,6 +38,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -77,7 +78,7 @@ static pthread_mutex_t arc4random_mtx = PTHREAD_MUTEX_INITIALIZER; static int rs_initialized; static struct arc4_stream rs; static pid_t arc4_stir_pid; -static int arc4_count; +static int* arc4_count; extern int __sysctl(int *name, u_int namelen, void *oldp, size_t *oldlenp, void *newp, size_t newlen); @@ -90,6 +91,12 @@ arc4_init(void) { int n; + if ((arc4_count = mmap(NULL, sizeof(int), PROT_READ|PROT_WRITE, + MAP_ANON|MAP_PRIVATE, -1, 0)) == MAP_FAILED) + abort(); + if (minherit(arc4_count, sizeof(int), INHERIT_ZERO) == -1) + abort(); + for (n = 0; n < 256; n++) rs.s[n] = n; rs.i = 0; @@ -174,7 +181,7 @@ arc4_stir(void) */ for (i = 0; i < 1024; i++) (void)arc4_getbyte(); - arc4_count = 1600000; + *arc4_count = 1600000; } static void @@ -182,7 +189,7 @@ arc4_stir_if_needed(void) { pid_t pid = getpid(); - if (arc4_count <= 0 || !rs_initialized || arc4_stir_pid != pid) + if (arc4_count == NULL || *arc4_count <= 0 || !rs_initialized || arc4_stir_pid != pid) { arc4_stir_pid = pid; arc4_stir(); @@ -237,7 +244,8 @@ arc4random(void) { u_int32_t val; _ARC4_LOCK(); - arc4_count -= 4; + if (arc4_count) + *arc4_count -= 4; arc4_stir_if_needed(); val = arc4_getword(); _ARC4_UNLOCK(); @@ -251,7 +259,7 @@ arc4random_buf(void *_buf, size_t n) _ARC4_LOCK(); arc4_stir_if_needed(); while (n--) { - if (--arc4_count <= 0) + if (--*arc4_count <= 0) arc4_stir(); buf[n] = arc4_getbyte(); } --------------090701060408080708060506-- From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 19 15:32:20 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 014087EC for ; Sat, 19 Jul 2014 15:32:20 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B1CEC250B for ; Sat, 19 Jul 2014 15:32:19 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X8WcO-0007de-3Y; Sat, 19 Jul 2014 15:32:12 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6JFWA6e026659; Sat, 19 Jul 2014 09:32:11 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19wEY1B/o4Q27KDdAjzP/NY X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [CFR] Adding a function to rtld-elf.so, how to handle Symbol.map? From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20140718155712.GM93733@kib.kiev.ua> References: <1405545833.1312.84.camel@revolution.hippie.lan> <20140717004537.GE93733@kib.kiev.ua> <1405616990.1312.111.camel@revolution.hippie.lan> <20140717172910.GH93733@kib.kiev.ua> <1405642661.1312.135.camel@revolution.hippie.lan> <20140718081455.GI93733@kib.kiev.ua> <1405689839.1312.148.camel@revolution.hippie.lan> <20140718133625.GL93733@kib.kiev.ua> <1405691354.1312.152.camel@revolution.hippie.lan> <20140718155712.GM93733@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Sat, 19 Jul 2014 09:32:10 -0600 Message-ID: <1405783930.85788.17.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 15:32:20 -0000 On Fri, 2014-07-18 at 18:57 +0300, Konstantin Belousov wrote: > On Fri, Jul 18, 2014 at 07:49:14AM -0600, Ian Lepore wrote: > > On Fri, 2014-07-18 at 16:36 +0300, Konstantin Belousov wrote: > > > On Fri, Jul 18, 2014 at 07:23:59AM -0600, Ian Lepore wrote: > > > > On Fri, 2014-07-18 at 11:14 +0300, Konstantin Belousov wrote: > > > > > On Thu, Jul 17, 2014 at 06:17:41PM -0600, Ian Lepore wrote: > > > > > > On Thu, 2014-07-17 at 20:29 +0300, Konstantin Belousov wrote: > > > > > > > On Thu, Jul 17, 2014 at 11:09:50AM -0600, Ian Lepore wrote: > > > > > > > > On Thu, 2014-07-17 at 03:45 +0300, Konstantin Belousov wrote: > > > > > > > > > On Wed, Jul 16, 2014 at 03:23:53PM -0600, Ian Lepore wrote: > > > > > > > > [snip] > > > > > > > > > > > > > > I did some looking around and Netbsd, Android, and Risc Os all > > > > > > > > implemented this in their dynamic loaders, so that seemed like the way > > > > > > > > to go. Android actually puts a function with this __gnu name in its > > > > > > > > libc, but all that function does is calls dl_unwind_find_exidx() which > > > > > > > > is implemented in their loader. > > > > > > > > > > > > > > > > I've just discovered that the arm unwind support code that will arrive > > > > > > > > as part of clang 3.5 appears to assume the Android way of things unless > > > > > > > > __LINUX__ is defined, so maybe it would be good to follow that model > > > > > > > > ourselves and add a dl_unwind_find_exidx() stub to libc/gen/dlfcn.c and > > > > > > > > name the new implementation in ld-elf to match. > > > > > > > I think that Android/__LINUX__ combination does the right thing, by > > > > > > > providing the symbol in libc. A libc implementation does not need any > > > > > > > additional service from rtld, except already existing _rtld_addr_phdr(). > > > > > > > > > > > > > > > > > > > Android provides a stub of dl_unwind_find_exidx() in libdl and the > > > > > > shared-object implementation in the dynamic linker. What it puts in > > > > > > libc is the __gnu_Unwind_Find_exidx() symbol, which just calls through > > > > > > to the dl_unwind_find_exidx() implementation in the dynamic linker. > > > > > > > > > > > > That aside, I've reworked my code so it all lives in libc instead of > > > > > > rtld, as you suggested. It seems to work fine, and I guess I'm agnostic > > > > > > about whether we're exporting a new function from libc versus rtld. It > > > > > > seems a bit strange to me to have just one dl_something() function with > > > > > > its shared/dynamic implementation in libc, while all the other functions > > > > > > with dl-prefix names are implemented in rtld. But not so weird that > > > > > > it's a big deal. > > > > > The new patch is fine with me. > > > > > > > > > > Could you, please, comment why did you decided to export the > > > > > dl_unwind_find_exidx alias ? It was absent in the original patch, > > > > > and from your description, it seems to be an implementation detail > > > > > on Linux. > > > > > > > > I think you might have misunderstood what I said earlier. According to > > > > comments in some clang 3.5 sources I saw, the clang project considers > > > > dl_unwind_find_exidx() to be "the BSD interface" for finding the exidx > > > > data. They fall back to the gnu name only when clang is compiled with > > > > __LINUX__ defined. By providing the functionality with this name, clang > > > > 3.5 will just work right on freebsd without needing to be modified to > > > > also use the gnu name when __FreeBSD__ is defined. > > > > > > > > Android and Netbsd provide dl_unwind_find_exidx(); I haven't checked > > > > other BSDs. It certainly is a better name for an interface shared by > > > > different toolchains than __gnu_Unwind_Find_exidx(), although we do need > > > > to also provide that symbol for anyone using gcc. > > > > > > Yes, I indeed misunderstood your description, thank you for the clarification. > > > I.e. clang on Linux and gcc use __gnu_Unwind_Find_exidx(), while (future) > > > clang on non-Linuxes uses dl_unwind_find_exidx() ? And there is no > > > ABI statement on the symbol, right ? > > > > Right, except I don't understand what you are asking in your last > > sentence. > > I ask, does ABI document requires the presence of the function ? > Does the spec defines interface for the function ? Unfortunately not, which has created a bit of a mess. The ARM EHABI spec defines how to handle exceptions in a way that works across toolchains and even across different languages. It defines a few data types and functions at the boundaries between the language-specific and -independant parts of the code, but doesn't get into implementation details. So it says how to use the exidx data, and even mentions that in a dynamic-loader environment there will be many separate exidx tables to search, but doesn't specify how that searching is done. The __gnu_Unwind_Find_exidx() uses an _Unwind_Ptr typedef. Every project and implementation of this stuff has its own different typedef for that type, scattered among different header files. Even within our current source base, if you grep typedef.*Unwind_Ptr you'll see that we have 5 typedefs of it as 4 different types. The same is true in other projects. Android has yet another different definition of it as unsigned long*. I decided to follow netbsd's lead and just declare the two pointers involved as void*. It's already hard to include a set of header files that works for all toolchains without getting re-typedef errors on that type, so I decided not to make the problem any worse by adding yet another typedef _Unwind_Ptr in yet another random header file. -- Ian