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