Date: Sat, 19 Jul 2014 09:32:10 -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: <1405783930.85788.17.camel@revolution.hippie.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1405783930.85788.17.camel>