platform_bionic/tests/libs/segment_gap_outer.cpp

#include <android/dlext.h>
#include <dlfcn.h>
#include <stdlib.h>

extern "C" void __attribute__((section(".custom_text"))) text_before_start_of_gap() {}
char __attribute__((section(".custom_bss"))) end_of_gap[0x1000];

extern "C" void* get_inner() {
  android_dlextinfo info = {};
  info.flags = ANDROID_DLEXT_RESERVED_ADDRESS;

  char* start_of_gap =
      reinterpret_cast<char*>(reinterpret_cast<uintptr_t>(text_before_start_of_gap) & ~0xfffull) +
      0x1000;
  info.reserved_addr = start_of_gap;
  info.reserved_size = end_of_gap - start_of_gap;

  void *handle = android_dlopen_ext("libsegment_gap_inner.so", RTLD_NOW, &info);
  if (!handle) {
    __builtin_trap();
  }

  return dlsym(handle, "inner");
}
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] https://github.com/llvm/llvm-project/blob/e739ac0e255597d818c907223034ddf3bc18a593/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-01 22:12:49 +01:00			`#include <android/dlext.h>`
			`#include <dlfcn.h>`
			`#include <stdlib.h>`

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 04:35:49 +02:00			`extern "C" void __attribute__((section(".custom_text"))) text_before_start_of_gap() {}`
			`char __attribute__((section(".custom_bss"))) end_of_gap[0x1000];`
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] https://github.com/llvm/llvm-project/blob/e739ac0e255597d818c907223034ddf3bc18a593/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-01 22:12:49 +01:00
			`extern "C" void* get_inner() {`
			`android_dlextinfo info = {};`
			`info.flags = ANDROID_DLEXT_RESERVED_ADDRESS;`

			`char* start_of_gap =`
			`reinterpret_cast<char*>(reinterpret_cast<uintptr_t>(text_before_start_of_gap) & ~0xfffull) +`
			`0x1000;`
			`info.reserved_addr = start_of_gap;`
			`info.reserved_size = end_of_gap - start_of_gap;`

			`void *handle = android_dlopen_ext("libsegment_gap_inner.so", RTLD_NOW, &info);`
			`if (!handle) {`
			`__builtin_trap();`
			`}`

			`return dlsym(handle, "inner");`
			`}`