| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Bug: http://b/19647373
Change-Id: I10e7682d9cec26a523f1a3597ca5326c3ca42ebe
(cherry picked from commit 1801db3d3fe17df543e721b9fb355e5c882dc6cc)
|
|
|
|
|
|
| |
This reverts commit e880c736d6c1d947f6309d5f1f63c74e8345c6a6.
Change-Id: Ide83e442eb5dbfef5298a15bc602c3fe1dda1862
|
|
|
|
|
|
|
| |
We want __libc_fini to be called after all the destructors.
Bug: 14611536
Change-Id: Ibb83a94436795ec178fd605fa531ac29608f4a3e
|
|
|
|
| |
Change-Id: Ia454a2181b5058ed9783dc02b6b1805d0e4d2715
|
|
|
|
| |
Change-Id: I023d2d8b547fbc21d4124bb7510d42b06a0dc501
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the linker's reliance on BSD cruft and use the glibc-style
ElfW macro. (Other code too, but the linker contains the majority
of the code that needs to work for Elf32 and Elf64.)
All platforms need dl_iterate_phdr_static, so it doesn't make sense
to have that part of the per-architecture configuration.
Bug: 12476126
Change-Id: I1d7f918f1303a392794a6cd8b3512ff56bd6e487
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: I2c1f3d34c33685799aade8866eec44479ff9f963
|
|
|
|
|
| |
Bug: 7959813
Change-Id: I8db4b8912ba649bfe668c6f22aa44690ddd401a2
|
|
There's now only one place where we deal with this stuff, it only needs to
be parsed once by the dynamic linker (rather than by each recipient), and it's
now easier for us to get hold of auxv data early on.
Change-Id: I6314224257c736547aac2e2a650e66f2ea53bef5
|