GitLab

For example:

@@@ ABORTING: INVALID HEAP ADDRESS IN dlfree addr=0x5c3bfbd0
Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 2942

The addr=0x5c3bfbd0 part is new.

Change-Id: I8670144b2b0a3a6182384150d762c97dfee5452f

Some SoCs that support NEON nevertheless perform better with a non-NEON than a
NEON memcpy().  This patch adds build variable ARCH_ARM_USE_NON_NEON_MEMCPY,
which can be set in BoardConfig.mk.  When ARCH_ARM_USE_NON_NEON_MEMCPY is
defined, we compile in the non-NEON optimized memcpy() even if the SoC supports
NEON.

Change-Id: Ia0e5bee6bad5880ffc5ff8f34a1382d567546cf9

So that we can always get the full stack trace regardless of gcc's handling
of the "noreturn" attribute associated with abort().

[cherry-picked from master]

BUG:6455193
Change-Id: I0102355f5bf20e636d3feab9d1424495f38e39e2

By default, Android no longer compiles code using it's custom
linker script /build/core/armelf.xsc. However, this causes
problems for libc. Certain programs linked using older versions
of GOLD expect libc.so to export __exidx_start and __exidx_end.
Removing the custom linker script causes libc.so not to export
those symbols.

For now, continue using the old linker script, until we can
figure out a better solution.

Change-Id: Iaf002afd63a58b848818da24e5a4525620dc4d74

Change-Id: I29ec4aa4843b9308cbfa412df88e026e8475b715
Signed-off-by: Mike Lockwood <lockwood@google.com>

The ARM static linker wasn't properly handling __exidx_start
and __exidx_end symbols. Now that the static linker has been fixed,
we don't need the dynamic linker to work around this problem.

Change-Id: I041b94903609fafab33663a7d441a5e70b7ffcdd

Change-Id: I79de18d04b950c21b985d5ebc01cd3306a43d318
Signed-off-by: Erik Gilling <konkers@android.com>

Change-Id: I38bb9498e18cb2b2e84a97487d4ad1e15fabd9d4
Signed-off-by: Erik Gilling <konkers@android.com>

This change mirrors cd15bacf for statically-linked binaries.

Change-Id: Id870832a50b37f0ef3e79e1ed03ed31390bfc9ef

Change-Id: I8184302daf61814d26c837f9920b4e68d96d7f65

Change-Id: I3854de8f4cddaf344444efa6f9da027642a237d9

Change-Id: Ifc5a10d9c2f7764ad80d64cc552aad81d5fbf5eb

* commit 'ff219e57':
  bionic: fix NULL parameter failure in getcwd()

* commit '418e647a':
  libstdc++: Fix x86 thread-safe one-time-construction implementation.

* commit '4994deae':
  Bionic: Fix wrong prototype of system call clock_nanosleep

* commit '7b8666e6':
  bionic: Fix wrong prototype of system call getresuid/getresgid

* commit '6435d27f':
  bionic: fix NULL parameter failure in getcwd()

In bionic/libc/SYSCALLS.TXT, the prototype of system call
clock_nanosleep is incorrect.

According to man page:
int clock_nanosleep(clockid_t clock_id, int flags,
                    const struct timespec *request,
                    struct timespec *remain);

Change-Id: Ic44c6db3d632293aa17998035554eacd664c2d57
Signed-off-by: Jin Wei <wei.a.jin@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>

In bionic/libc/SYSCALLS.TXT, the prototypes of system call
getresuid/getresgid are incorrect.

According to man page, they should be:
    int getresuid(uid_t *ruid, uid_t *euid, uid_t *suid);
    int getresgid(gid_t *rgid, gid_t *egid, gid_t *sgid);

Change-Id: I676098868bb05a9e1fe45419b234cf397626fdad
Signed-off-by: Jin Wei <wei.a.jin@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>

LTP: getcwd01 failed in LTP

Need to check getcwd parameters, otherwise it will lead to
posix test case to fail.

Change-Id: Ieb673b6dd4ca6481da81c5339dbf7ec0a463f263
Signed-off-by: Jin Wei <wei.a.jin@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>

The root of the problem is that the existing implementation is based on the
ARM C++ ABI, which mandates a different guard variable layout than the
Itanium/x86 C++ one.

This patch modifies the implementation in a way that satisfies both ABIs (and
doesn't require changing the toolchains).

Change-Id: I885e9adc7f088b9c0a78355bd752f1e6aeec9f07
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
Signed-off-by: Jack Ren <jack.ren@intel.com>
Signed-off-by: Bruce Beare <bruce.j.beare@intel.com>

* commit 'cebc8fb0':
  libm: fix invalid result of function remquo/remquof

* commit '6bc18fa5':
  libm: fix invalid result of function remquo/remquof

* changes:
  Add faccessat to syscall list
  Update unistd.h for new syscalls

Change-Id: I427a18811089cb280769ac8da3ed8adc00a65a10

gensyscalls.py run from external/kernel-headers at commit
efab8f3e49f7f36ef0354b0996ecd5f3fa031e52

Change-Id: I959b64280e184655ef8c713aa79f9e23cb1f7df4

* commit '0613dce0':
  regenerate linux/fb.h

Change-Id: Icd8c0f53306a48ffd513378abdf387af21e886a3

Since e19d702b, dlsym and friends use recursive mutexes that
require the current thread id, which is not available before the libc
constructor. This prevents us from using dlsym() in .preinit_array.

This change moves TLS initialization from libc constructor to the earliest
possible point - immediately after linker itself is relocated. As a result,
pthread_internal_t for the initial thread is available from the start.

As a bonus, values stored in TLS in .preinit_array are not lost when libc is
initialized.

Change-Id: Iee5a710ee000173bff63e924adeb4a4c600c1e2d

The END macro was put too far down which made the linker complain about
it. Move up to the end of the code.

Change-Id: Ica71a9c6083b437d2213c7cefe34b0083c78f16b

Marking segments read-only was pushing the alignment of __on_dlclose by
2 bytes making it unaligned. This change makes sure the ARM code is
aligned to the 4 byte boundary.

Bug: 6313309
Change-Id: Ic2bf475e120dd61225ec19e5d8a9a8b1d0b7f081

This reverts commit 61ff8347.

This code is harmless, and only applies to the linker, so
there's no harm in keeping it in the tree a little bit longer.
Let's roll this back while we try to figure out the root cause
of bug 6314858.

Bug: 6314858
Change-Id: I9f5ed81d23a7abe273baf792aa8a0a2839ef094c

This change fixes a segmentation fault in the libc unwinder when it goes
past __libc_init.

Unwind instructions for __libc_init direct it to grab the return address from
the stack frame. Without this change, the unwinder gets a wild address and
looks up further unwind instructions for the routine at that address. If it's
unlucky enough to hit an existing function, it will try to unwind it. Bad
things happen then.

With this change, the return address always points to the _start function,
which does not have unwind instructions associated with it. This stop the
unwind process.

__libc_init never returns, so this does not affect program execution, other
than adding 4 bytes on the main thread stack.

Change-Id: Id58612172e8825c8729cccd081541a13bff96bd0