crt_pad_segment provides a note of type NT_ANDROID_TYPE_PAD_SEGMENT.
It's intended when present is for the loader to pad segment gaps to
reduce kernel slab memory usage (due to additional vm_area_struct's
for gaps). crt_pad_segment.o retains control to the static linker so
that app developers can opt out (build with different flags) it there
are undesireable side effects.
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00 0 0 0
[ 1] .strtab STRTAB 0000000000000000 0000f8 000066 00 0 0 1
[ 2] .text PROGBITS 0000000000000000 000040 000000 00 AX 0 0 4
[ 3] .note.GNU-stack PROGBITS 0000000000000000 000040 000000 00 0 0 1
[ 4] .note.android.pad_segment NOTE 0000000000000000 000040 00001c 00 A 0 0 4
[ 5] .rela.note.android.pad_segment RELA 0000000000000000 0000e0 000018 18 I 7 4 8
[ 6] .debug_line PROGBITS 0000000000000000 00005c 000052 00 0 0 1
[ 7] .symtab SYMTAB 0000000000000000 0000b0 000030 18 1 1 8
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
D (mbind), l (large), p (processor specific)
Bug: 316403210
Test: m -j50 ndk
Test: find out/soong/ndk -name 'crt_pad_segment.o'
Test: readelf -SW crt_pag_segment.o
Change-Id: I94af5e85fd602e7ba5fd56788ae39277368229d8
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Currently, we use sentinels (starting with -1 and ending with 0) in
preinit_array/init_array/fini_array in executables. But after using LTO,
the sentinels can be reordered by LLD and no longer work. So make below
changes to not rely on them:
1. In crtbegin.c, use symbols (like __init_array_start) inserted by the
linker.
2. Add array_count fields in structors_array_t.
3. In static libc, use array_count fields to decide array lengths.
4. To make new dynamic executables work with old libc.so, create a fake
fini_array with sentinels, and pass it to __libc_init. The fake
fini_array contains a function to call functions in real fini_array.
5. To make old dynamic executables work with new libc.so, libc.so
still uses sentinels to decide the length of fini_array.
Bug: 295944813
Bug: https://github.com/android/ndk/issues/1461
Test: run bionic-unit-tests-static
Test: test static executables manually
Test: boot cf_gwear_x86-trunk_staging-userdebug
Change-Id: I1ce31f07bcfe0e99b4237984898a8fc9e98ff426
There's negative value to explicitly calling out Linux and ELF here,
when Android -- and especially this project -- is always both anyway.
No functional change.
Test: treehugger
Change-Id: Ic7514d74a5b5f6f06e64c46486c12773995076cd
Normally, platform-specific note types in the toolchain are prefixed
with the platform name. Because we're exposing the NT_TYPE_MEMTAG and
synthesizing the note in the toolchain in an upcoming patch
(https://reviews.llvm.org/D118948), it's been requested that we change
the name to include the platform prefix.
While NT_TYPE_IDENT and NT_TYPE_KUSER aren't known about or synthesized
by the toolchain, update those references as well for consistency.
Bug: N/A
Test: Build Android
Change-Id: I7742e4917ae275d59d7984991664ea48028053a1
I don't know when LLVM's x86 assembler started making the same
assumptions as GAS used to, but I'm happy to get rid of "calll".
Test: treehugger
Change-Id: I0a924993aebf7d701a846805fea9a015e8feb58a
This CL adds an instruction to the _start label that clears the frame
pointer. This allows stack walking code to determine when it has
reached the end of the stack.
The __bionic_clone function is similarly modified, for architectures
that weren't already doing both.
Test: bionic-unit-tests
Test: CtsBionicTestCases
Change-Id: Iea3949f52c44f7931f9fff2d60d4d9e5c742c120
As far as I can tell, clang never implemented this GCC workaround for
32-bit x86's terrible PIC code. Since the whole point of
__stack_chk_fail_local() requires that it's in the same executable or
library as its callers, any prebuilt with a dependency on this (because
it was built by GCC) already has its own copy anyway. And clang isn't
creating any new ones, so I think this has been dead for several years
now.
Test: treehugger
Change-Id: I96997bbf912bbff506db44c285d9941fef9f86ce
Motivated by the fact that bazel doesn't like #include "../", but this
feels like it could use a deeper clean.
In fact, even after this change, I think we should remove this entirely,
since as far as I can tell Clang never implemented this GCC workaround
for 32-bit x86's awful PIC code.
Test: treehugger
Change-Id: I72715ee46f873f42d5707712aebe246ef78fcde1
The toolchain is new enough that should be able to use the actual
instructions now...
Test: treehugger
Change-Id: I30aafcdc5386268344c40dc6cc9a22caf591915a
A constructor or destructor function with an integral priority is
placed in an .init_array or .fini_array section with the priority
suffixed to the section name:
- __attribute__((constructor)) ==> .init_array
- __attribute__((constructor(42))) ==> .init_array.42
The suffixed init/fini sections appear before the unsuffixed sections,
so the prioritized functions appeared before the __{INIT,FINI}_ARRAY__
symbols and were dropped when the symbols were used.
The (static) linker doesn't recognize priority suffixes on
.preinit_array.
This bug affected .init_array and .fini_array for static executables.
For dynamic executables, only .fini_array was affected, because
.init_array is handled by the dynamic loader instead, which uses
DT_INIT_ARRAY[SZ]. For DSOs, neither is affected, because the two
sections are only handled by the dynamic loader.
This patch also fixes a minor inconsistency where dynamic init/preinit
were passed argc/argv/envp, but static were not.
Bug: http://b/170983066
Test: bionic-unit-tests
Change-Id: I0fffa776e5d9bdb6f8af06b4c1af148236742fef
Every architecture that uses .eh_frame needs a terminator at the end to
ensure that an unwinder library doesn't read past the end of the
section. This can happen when the unwinder looks up a PC that doesn't
have a matching FDE. Both LLVM libunwind and libgcc fall back to an
.eh_frame scan if the .eh_frame_hdr search table scan fails.
By convention, this terminator section is aligned to 4, even on 64-bit
targets. e.g. Both libgcc and compiler-rt have a crtend with 4-byte
.eh_frame alignment on arm64 and x86_64.
In practice, lld strips off the terminator from input object files and
adds one unconditionally to the output, but bfd/gold still require a
crtend with a terminator.
References:
- https://reviews.llvm.org/D86256
- https://reviews.llvm.org/D87750
- https://sourceware.org/bugzilla/show_bug.cgi?id=2655
Test: examine crtend.o and crtend_so.o with `readelf -SW` and \
`objdump -Wf`
Change-Id: Ib8478ee446ad806898aa7147a6208d384c7516d5
These files are linked to all ELF files therefore they must support BTI.
Test: Tested on FVP with BTI enabled using a patched clang.
Co-authored-by: Gabor Kertesz <gabor.kertesz@arm.com>
Co-authored-by: Daniel Kiss <daniel.kiss@arm.com>
Co-authored-by: Tamas Petz <tamas.petz@arm.com>
Change-Id: If5df0722e649bcdb8c4afb0531831dff42103c9c
Historically we've made a few mistakes where they haven't matched the
right number. And most non-Googlers are much more familiar with the
numbers, so it seems to make sense to rely more on them. Especially in
header files, which we actually expect real people to have to read from
time to time.
Test: treehugger
Change-Id: I0d4a97454ee108de1d32f21df285315c5488d886
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
Android's current lld build has a hack that overaligns TLS segments, but
it broke glibc when it produced TLS segments where (p_vaddr % p_align) was
non-zero. Move the hack into Bionic's crtbegin instead. It will emit a
0-sized, 64-byte alignment TLS segment into executables that don't use
TLS, but that should be harmless.
This variant of the hack is compatible with the gold and lld linkers. The
ld.bfd linker will optimize the .tdata output section out if its size is
zero, preventing the overalignment in an executable that only has .tbss
sections. This problem could be fixed by adding a ". = .;" statement
inside .tdata in ld.bfd's linker script.
See discussion on https://reviews.llvm.org/D61824.
Bug: https://bugs.llvm.org/show_bug.cgi?id=41527
Test: bionic unit tests, boot a device
Change-Id: I34df8b5594b6518d4590e4861e3d0b74d6fa754e
Fixes a build error when PLATFORM_SDK_VERSION is not set.
Bug: 31559095
Test: attempt to build host bionic
Change-Id: I9cbdcea206ef1239c330a5adafbfa5cc797fef5e
We want to delay the emutls pthread key deletion to keep
__thread/thread_local variables working as long as possible.
Currently, emutls has its own __attribute__((destructor)) function that
deletes its pthread key. That function runs even on process exit, and it
can run before other destructor functions and before C++ static object
destructors.
Move the destructor function to crtbegin_so.c, where an
__attribute__((destructor)) function is only called on dlclose. Use a
priority 0 destructor, which runs after every destructor with a default or
greater priority value.
__emutls_unregister_key will still run before destructor functions of
DT_NEEDED solibs. It also still leaks memory (both the emutls arrays and
each emutls object).
Bug: b/80453944
Test: manual
Change-Id: I6789bcf168415ab8badf2f64687c6a0136c5c917
The (lowest) address of the argument area (aka ESP immediately prior to
the call instruction) must be aligned to 0 mod 16. Here, it is aligned to
12 mod 16.
From the SysV ABI doc (2.2.2 The Stack Frame)
"""The end of the input argument area shall be aligned on a 16 (32, if
__m256 is passed on stack) byte boundary. In other words, the value
(%esp + 4) is always a multiple of 16 (32) when control is transferred to
the function entry point."""
Test: extract code into a separate C file and verify stack alignment in a
"start_main" function
Test: use the upcoming NDK r17-beta1 (with new Bionic crtbegin*.o files)
with an M-23 x86 system image, check alignment in main (compiled with
Clang not GCC, compiled w/o -mstackrealign)
Bug: b/73140672
Change-Id: Ia8d93fe5668d0a514a9fd22c40bf8362805111e6
These sources are going to be used for the NDK as well, and the NDK
still uses GCC.
This partially reverts commit
4af220cfef. That commit also removed
this symbol from the linker's crtbegin (it has its own). That is
still only built with Clang, so we don't need to revert that part.
Test: treehugger
Bug: None
Change-Id: Iba231baf298e228135bdf48dfed87f9089975eb1
We're going to start using the bionic sources for the NDK CRT
objects, so we need to avoid using symbols that weren't around in
early versions of Android. The NDK is currently building the CRT
objects with GCC as well (there were some segfaults that have yet to
be diagnosed), so move `__used` to the GCC compatible location.
Test: treehugger
Bug: None
Change-Id: I1f5c23eafadc2e3bc0b84bc3305f79a04d35c7d8
Use .balign because what the argument means doesn't vary between
architectures.
Bug: http://b/70166421
Test: builds
Change-Id: I1d54f2f6942dd2893f3fda30bac08d07ea9cd346
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
If _start_main is static, clang optimizes it out and then generates an
undefined reference from the inline assembler, so let's explicitly tell
the compiler it's used.
Bug: N/A
Test: ran tests
Change-Id: Iba3d9c63abae9a0dc32f236b01783515f0190956
Using __builtin_frame_address was clever, but didn't work for arm64 (for
reasons which were never investigated) and the ChromeOS folks claim it
causes trouble for x86 with ARC++ (though without a reproduceable test case).
Naked functions turn out to be quite unevenly supported: some architectures
do the right thing, others don't; some architectures warn, others don't (and
the warnings don't always match the platforms that _actually_ have problems).
Inline assembler also removes the guessing games: everyone knows what the
couple of instructions _ought_ to be, and now we don't have to reason about
what the compiler will actually do (yet still keep the majority of the code
in C).
Bug: N/A
Test: builds, boots
Change-Id: I14207ef50ca46b6eca273c3cb7509c311146a3ca
The visibility control in pthread_atfork.h is incorrect.
It breaks 64bit libc.so by hiding pthread_atfork.
This reverts commit 6df122f852.
Change-Id: I21e4b344d500c6f6de0ccb7420b916c4e233dd34
The .note.android.ident section is only used by GDB, which doesn't
care what section type the section is, but it would be convenient
for readelf -n to be able to find the section too.
The old way of getting the .note.android.ident section to be of type
SH_NOTE involved compiling from .c to .s using gcc, running sed to
change progbits to note, and then compiling from .s to .o using gcc.
Since crtbrand.c only contains a section containing data, a
crtbrand.S can be checked in that will compile on all platforms,
avoiding the need for sed.
Also add crtbrand.o to crtbegin_so.o so that libraries also get
the note, and to the crt workaround in arm libc.so.
Change-Id: Ica71942a6af4553b56978ceaa288b3f4c15ebfa2
* Ability to register atexit handler from atexit handler
* Correct way to handle both forms of atexit handler
Bug: https://code.google.com/p/android/issues/detail?id=66595
Bug: 4998315
Change-Id: I39529afaef97b6e1469c21389d54c0d7d175da28
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
Got it all wrong on first patch. Somehow that didn't affect system
build, neither arm nor x86... something to think about.
Change-Id: I45416d843aad44af62841c6f6ab607ccf3f012ea
Signed-off-by: Pavel Chupin <pavel.v.chupin@intel.com>
