Date: Thu, 17 Jul 2014 20:29:10 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Ian Lepore <ian@FreeBSD.org> Cc: hackers@freebsd.org Subject: Re: [CFR] Adding a function to rtld-elf.so, how to handle Symbol.map? Message-ID: <20140717172910.GH93733@kib.kiev.ua> In-Reply-To: <1405616990.1312.111.camel@revolution.hippie.lan> References: <1405545833.1312.84.camel@revolution.hippie.lan> <20140717004537.GE93733@kib.kiev.ua> <1405616990.1312.111.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140717172910.GH93733>