Commit graph

3 commits

Author SHA1 Message Date
Stephen Hines
15027e048f Specify sections to merge in segment_gap_outer.lds more precisely
https://reviews.llvm.org/D75225 changed the way that orphan sections are
retained, breaking this test. The test relied on these sections being
merged in an implementation-defined order that no longer holds true. We
can use custom sections to place the symbols we want more precisely.

Bug: http://b/161943302
Test: adb shell /data/nativetest64/bionic-unit-tests/bionic-unit-tests --gtest_filter=dlfcn.segment_gap --no_isolate
Change-Id: I65656080e39be16833191cb92d3d4c41e409b216
2020-07-24 10:57:48 -07:00
Orion Hodson
e7042a740e Remove unnecessary jni.h
Discovered after removing implicit jni.h include path.

Bug: 152482542
Test: lunch aosp_x86_64 && m checkbuild
Change-Id: I5fcb33b110c8f5ee9db3c910eaaa3e6018979a45
2020-04-07 09:21:41 +01:00
Peter Collingbourne
b39cb3c31d linker: Handle libraries with disjoint mappings correctly.
It's possible and sometimes beneficial for a library to have disjoint mappings
and for other libraries to be mapped into the gap between the mappings using
ANDROID_DLEXT_RESERVED_ADDRESS. See for example the proposal for partitioning
in lld [1].

Because the find_containing_library and do_dl_unwind_find_exidx functions use
a simple bounds check to figure out whether a pointer belongs to a library
they will, given a pointer into a library mapped into the gap of a library
with disjoint mappings, return a pointer to the soinfo for the outer library
instead of the inner one, because the outer library will appear before the
inner one in the solist.

From a user perspective this means that we won't be able to unwind the inner
library's frames on 32-bit ARM with libgcc, dladdr() will return information
for the outer library given a pointer to the inner one and dlopen() et al will
use the linker namespace of the outer library when called from the inner one
(although they will usually be the same).

To make this work correctly, make it so that once find_containing_library
sees a match for the bounds check, it examines the library's PT_LOADs to
make sure that there is a mapping for the given address. This is similar
to how libgcc and libunwind_llvm already handle finding the PT_GNU_EH_FRAME
on non-ARM32 platforms [2,3]. do_dl_unwind_find_exidx is reimplemented in
terms of find_containing_library.

[1] http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html
[2] e739ac0e25/libunwind/src/AddressSpace.hpp (L523)
[3] https://android.googlesource.com/toolchain/gcc/+/master/gcc-4.9/libgcc/unwind-dw2-fde-dip.c#294

Test: /data/nativetest{,64}/bionic-unit-tests/bionic-unit-tests on walleye-userdebug
Change-Id: I368fe6ad3c470b3dff80f7d9b04253566d63a7d2
2019-03-08 18:34:34 -08:00