arm32 has two special APIs to find exidx exception handling info,
dl_unwind_find_exidx and __gnu_Unwind_Find_exdix. The two functions have
identical behavior and function prototypes. libgcc's arm32 unwinder calls
__gnu_Unwind_Find_exdix, whereas LLVM's libunwind previously called
__gnu_Unwind_Find_exdix, but switched to dl_unwind_find_exidx as a result
of three patches (D30306, D30681, D39468).
In Bionic, for dynamic linking, __gnu_Unwind_Find_exdix in libc.so calls
dl_unwind_find_exidx in libdl.so.
For static executables, though, __gnu_Unwind_Find_exdix in libc.a used the
__exidx_* symbols, while dl_unwind_find_exidx in libdl.a(libdl_static.o)
was a return-0 no-op.
To fix the LLVM unwinder, replace the no-op dl_unwind_find_exidx in
libdl.a with a real function in libc.a(exidx_static.o), and have the GNU
function call the dl function for more consistency with dynamic linking.
dl_iterate_phdr follows a similar pattern, where the function exists in
libc.a and libdl.so (not libc.so or libdl.a).
This change makes unwinding work with an updated libunwind_llvm on arm32,
and it helps to allow unwinding in static executables without libdl.a.
Bug: https://github.com/android/ndk/issues/1094
Bug: http://b/141485154
Test: NDK tests, bionic unit tests
Change-Id: Ieeeb9b39a0e28544e21f9afe6fe51ef10d7c828c
Seems only logical, given that all the other calls fail.
(Only thing that's weird about this is that calling dlerror() usually
clears the error until you do something else that causes an error, but
that doesn't seem worth the bookkeeping?)
Bug: https://github.com/android-ndk/ndk/issues/965
Test: static unit tests still pass
Change-Id: I5e5401e148c5857f1dbab9c5a7f4a6fc43d8d626
