Most DSOs have a RELRO segment, but some of them have nothing except
__dso_handle in their .data section. This means __dso_handle is taking
up a page as well as a vm_area_struct in kernel slabs for those DSOs.
Let's move it to the RELRO segment to save memory.
On a 32-bit device I tested on, I saw ~400 KB less slab usage on
vm_area_struct. To control for difference in number of cached
processes, I also measured with Android stopped, and I saw ~100 KB less
slab usage. Summing up all dirty pages attributed to shared libraries,
I saw 5.6 MB less dirty pages.
Test: Build and boot.
Change-Id: Ib88e49f1c72352e610affc19623895d954110d4e
e210488e0d in 2013 added this, which seems
to have been a workaround for the linker at the time that was never removed.
Bug: N/A
Test: ran tests
Change-Id: I171c3f4b7c34638ab75b8e49616b3a9c24ab3fcb
This is the first patch out of a series of patches that add support for
AArch64, the new 64bit execution state of the ARMv8 Architecture. The
patches add support for LP64 programming model.
The patch adds:
* "arch-aarch64" to the architecture directories.
* "arch-aarch64/include" - headers used by libc
* "arch-aarch64/bionic":
- crtbegin, crtend support;
- aarch64 specific syscall stubs;
- setjmp, clone, vfork assembly files.
Change-Id: If72b859f81928d03ad05d4ccfcb54c2f5dbf99a5
Signed-off-by: Serban Constantinescu <serban.constantinescu@arm.com>
The x86_64 build was failing because clone.S had a call to __thread_entry which
was being added to a different intermediate .a on the way to making libc.so,
and the linker couldn't guarantee statically that such a relocation would be
possible.
ld: error: out/target/product/generic_x86_64/obj/STATIC_LIBRARIES/libc_common_intermediates/libc_common.a(clone.o): requires dynamic R_X86_64_PC32 reloc against '__thread_entry' which may overflow at runtime; recompile with -fPIC
This patch addresses that by ensuring that the caller and callee end up in the
same intermediate .a. While I'm here, I've tried to clean up some of the mess
that led to this situation too. In particular, this removes libc/private/ from
the default include path (except for the DNS code), and splits out the DNS
code into its own library (since it's a weird special case of upstream NetBSD
code that's diverged so heavily it's unlikely ever to get back in sync).
There's more cleanup of the DNS situation possible, but this is definitely a
step in the right direction, and it's more than enough to get x86_64 building
cleanly.
Change-Id: I00425a7245b7a2573df16cc38798187d0729e7c4
2013-10-09 16:00:17 -07:00
Renamed from libc/private/__dso_handle_so.h (Browse further)
