From the release notes:
Changes affecting future time stamps
Turks & Caicos is switching from US eastern time to UTC-4 year-round,
modeled as a switch from EST/EDT to AST on 2014-11-02 at 02:00.
Changes affecting past time stamps
Time in Russia or the USSR before 1926 or so has been corrected by
a few seconds in the following zones: Asia/Irkutsk,
Asia/Krasnoyarsk, Asia/Omsk, Asia/Samarkand, Asia/Tbilisi,
Asia/Vladivostok, Asia/Yakutsk, Europe/Riga, Europe/Samara. For
Asia/Yekaterinburg the correction is a few minutes. (Thanks to
Vladimir Karpinsky.)
The Portuguese decree of 1911-05-26 took effect on 1912-01-01.
This affects 1911 time stamps in Africa/Bissau, Africa/Luanda,
Atlantic/Azores, and Atlantic/Madeira. Also, Lisbon's pre-1912
GMT offset was -0:36:45 (rounded from -0:36:44.68), not -0:36:32.
(Thanks to Stephen Colebourne for pointing to the decree.)
Asia/Dhaka ended DST on 2009-12-31 at 24:00, not 23:59.
A new file 'backzone' contains data which may appeal to
connoisseurs of old time stamps, although it is out of scope for
the tz database, is often poorly sourced, and contains some data
that is known to be incorrect. The new file is not recommended
for ordinary use and its entries are not installed by default.
(Thanks to Lester Caine for the high-quality Jersey, Guernsey, and
Isle of Man entries.)
Some more zones have been turned into links, when they differed
from existing zones only for older time stamps. As usual,
these changes affect UTC offsets in pre-1970 time stamps only.
Their old contents have been moved to the 'backzone' file.
The affected zones are: Africa/Bangui, Africa/Brazzaville,
Africa/Douala, Africa/Kinshasa, Africa/Libreville, Africa/Luanda,
Africa/Malabo, Africa/Niamey, and Africa/Porto-Novo.
Bug: 17277574
(cherry picked from commit 9685c30a2375635f7410e60eff2f0559f7e84df6)
Change-Id: I6120be3a0ec76af2d07ca6f9ea6f83d81d215803
Stdatomic.h was potentially redefining _Atomic, in spite of a
prior definition by <atomic>. This could cause g++ builds that
included <stdatomic.h> with an available <atomic> header to break.
A functional stdatomic.h is a prerequisite for fixing the
following bugs. This is the middle of 3 AOSP updates to
bionics stdatomic.h that are needded to get there.
Bug:16880454
Bug:16513433
Change-Id: I562c7115118c0587d594d4d5b62d25101e47bfd8
(cherry picked from commit 3e4a0099a179d7acee63d78c8fc4c3cc7b0bae42)
We seem to use this stdatomic.h sometimes, and slightly different prebuilts
at other times, making them all difficult to test, and making it unclear
which one we're testing. This generalizes the bionic header so that it
can be used directly as the prebuilt header as well. So long as they
don't diverge again, that should somewhat improve test coverage.
Use the correct builtin for atomic_is_lock_free.
Fix atomic_flag_init.
Turn on atomic tests even with __GLIBC__, since they now appear to pass.
Include uchar.h in stdatomic.h where needed.
Add a basic memory ordering test.
Fix bit-rotted comments in bionic tests makefile.
Prerequisite for fixing b/16880454 and
Bug:16513433
Change-Id: If6a14c1075b379395ba5d93357d56025c0ffab68
(cherry picked from commit 00aaea364501b3b0abe58dae461136159df1e356)
From the release notes:
Changes affecting future time stamps
Turks & Caicos is switching from US eastern time to UTC-4 year-round,
modeled as a switch from EST/EDT to AST on 2014-11-02 at 02:00.
Changes affecting past time stamps
Time in Russia or the USSR before 1926 or so has been corrected by
a few seconds in the following zones: Asia/Irkutsk,
Asia/Krasnoyarsk, Asia/Omsk, Asia/Samarkand, Asia/Tbilisi,
Asia/Vladivostok, Asia/Yakutsk, Europe/Riga, Europe/Samara. For
Asia/Yekaterinburg the correction is a few minutes. (Thanks to
Vladimir Karpinsky.)
The Portuguese decree of 1911-05-26 took effect on 1912-01-01.
This affects 1911 time stamps in Africa/Bissau, Africa/Luanda,
Atlantic/Azores, and Atlantic/Madeira. Also, Lisbon's pre-1912
GMT offset was -0:36:45 (rounded from -0:36:44.68), not -0:36:32.
(Thanks to Stephen Colebourne for pointing to the decree.)
Asia/Dhaka ended DST on 2009-12-31 at 24:00, not 23:59.
A new file 'backzone' contains data which may appeal to
connoisseurs of old time stamps, although it is out of scope for
the tz database, is often poorly sourced, and contains some data
that is known to be incorrect. The new file is not recommended
for ordinary use and its entries are not installed by default.
(Thanks to Lester Caine for the high-quality Jersey, Guernsey, and
Isle of Man entries.)
Some more zones have been turned into links, when they differed
from existing zones only for older time stamps. As usual,
these changes affect UTC offsets in pre-1970 time stamps only.
Their old contents have been moved to the 'backzone' file.
The affected zones are: Africa/Bangui, Africa/Brazzaville,
Africa/Douala, Africa/Kinshasa, Africa/Libreville, Africa/Luanda,
Africa/Malabo, Africa/Niamey, and Africa/Porto-Novo.
Bug: 17277574
Change-Id: Idff4a68e927d49bef1e787af534e1b23b5b8a7fb
This is needed to make L work correctly, and bionic tests pass
again, after applying the equivalent of
commit 00aaea364501b3b0abe58dae461136159df1e356 there.
It makes the preexisting code that uses __sync implementations
much more useful, although we should no longer be exercising that
code in AOSP.
Specifically fixes:
We were invoking __has_extension and __has_builtin for GCC compilations.
They're clang specific. Restructured the tests.
The __sync implementation was not defining the LOCK_FREE macros.
ATOMIC_VAR_INIT was using named field initializations. These are a
C, not C++, feature, that is not supported by g++ 4.6.
The stdatomic bionic test still failed with 4.6 and glibc with our
questionable LOCK_FREE macro implementation. Don't run that piece
with 4.6.
In L, this is a prerequisite for fixing:
Bug:16880454
Bug:16513433
Change-Id: I9b61e42307f96a114dce7552b6ead4ad1c544eab
We already had the POSIX strerror_r, but some third-party code defines
_GNU_SOURCE and expects to get the GNU strerror_r instead.
This exposed a bug in the libc internal logging functions where unlike
their standard brethren they wouldn't return the number of bytes they'd
have liked to have written.
Bug: 16243479
Change-Id: I1745752ccbdc569646d34f5071f6df2be066d5f4
GCC assembler allows xyz to be redeclared as weak,
by __weak_alias(xyz, _xyz), while _xyz is undefined.
Clang does not like that but silently generates no code.
It will reject its own .s file if the assembly code is saved first.
Since we have no reason to define xyz or _xyz as weak symbol now,
and _xyz is a macro to xyz, we simplify libC to have only
xyz defined as global.
BUG: 17186746
Change-Id: I24b154425838683cae69248cc750c59e26fd5467
...rather than just what's already mapped in. This seems somewhat
contrary to POSIX's "All pages within the stack described by stackaddr
and stacksize shall be both readable and writable by the thread", but
it's what glibc does.
Bug: 17111575
(cherry picked from commit 9e4ffa7032eaab308876b8e3da86b05c3c613878)
Change-Id: I73f219a569917b2e4546c09436d7ef5231facc07
...rather than just what's already mapped in. This seems somewhat
contrary to POSIX's "All pages within the stack described by stackaddr
and stacksize shall be both readable and writable by the thread", but
it's what glibc does.
Bug: 17111575
Change-Id: If9e2dfad9a603c0d0615a8123aacda4946e95b2c
This speeds up the debug malloc code by using the original unwinding code.
The only catch is that it has to link in the libc++ arm unwind code or
there will be crashes when attempting to unwind through libc++ compiled
code.
Bug: 16874447
(cherry picked from commit 3f7635f4906c53fa744731efc35235456b7d93bf)
Change-Id: If8a3821cdd95ed481bb496bf2daab449d13790f8
This speeds up the debug malloc code by using the original unwinding code.
The only catch is that it has to link in the libc++ arm unwind code or
there will be crashes when attempting to unwind through libc++ compiled
code.
Bug: 16874447
Change-Id: Ifdbbcbd4137d668b25cf3c2bd59535e06ebfa5a7
Stdatomic.h was potentially redefining _Atomic, in spite of a
prior definition by <atomic>. This could cause g++ builds that
included <stdatomic.h> with an available <atomic> header to break.
Change-Id: I562c7115118c0587d594d4d5b62d25101e47bfd8
On most architectures the kernel subtracts a random offset to the stack
pointer in create_elf_tables by calling arch_align_stack before writing
the auxval table and so on. On all but x86 this doesn't cause a problem
because the random offset is less than a page, but on x86 it's up to two
pages. This means that our old technique of rounding the stack pointer
doesn't work. (Our old implementation of that technique was wrong too.)
It's also incorrect to assume that the main thread's stack base and size
are constant. Likewise to assume that the main thread has a guard page.
The main thread is not like other threads.
This patch switches to reading /proc/self/maps (and checking RLIMIT_STACK)
whenever we're asked.
Bug: 17111575
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
(cherry picked from commit 57b7a6110e7e8b446fc23cce4765ff625ee0a105)
Change-Id: I87e679ee1c0db8092f2d1221c8e7c1461545c5a4
On most architectures the kernel subtracts a random offset to the stack
pointer in create_elf_tables by calling arch_align_stack before writing
the auxval table and so on. On all but x86 this doesn't cause a problem
because the random offset is less than a page, but on x86 it's up to two
pages. This means that our old technique of rounding the stack pointer
doesn't work. (Our old implementation of that technique was wrong too.)
It's also incorrect to assume that the main thread's stack base and size
are constant. Likewise to assume that the main thread has a guard page.
The main thread is not like other threads.
This patch switches to reading /proc/self/maps (and checking RLIMIT_STACK)
whenever we're asked.
Bug: 17111575
Signed-off-by: Fengwei Yin <fengwei.yin@intel.com>
Change-Id: I1d4dbffe7bc7bda1d353c3a295dbf68d29f63158
Without these specs, clang will reports mismatch between standard definitions and these declarations/definitions. These specs are ignored when compiled with -fno-exceptions.
BUG: 17136236
Change-Id: I386c712a61dc4fc74dfde45f9ec2d3d037f2e9f1
