blob: 5e3ae4590a8ecc2d4ee969ade35229d1c133adcb [file] [log] [blame] [view]
Elliott Hughes0bfcbaf2017-08-28 09:18:34 -0700132-bit ABI bugs
2===============
3
4`off_t` is 32-bit
5-----------------
6
7On 32-bit Android, `off_t` is a signed 32-bit integer. This limits functions
8that use `off_t` to working on files no larger than 2GiB.
9
10Android does not require the `_LARGEFILE_SOURCE` macro to be used to make
11`fseeko` and `ftello` available. Instead they're always available from API
12level 24 where they were introduced, and never available before then.
13
14Android also does not require the `_LARGEFILE64_SOURCE` macro to be used
15to make `off64_t` and corresponding functions such as `ftruncate64` available.
16Instead, whatever subset of those functions was available at your target API
17level will be visible.
18
19There are a couple of exceptions to note. Firstly, `off64_t` and the single
20function `lseek64` were available right from the beginning in API 3. Secondly,
21Android has always silently inserted `O_LARGEFILE` into any open call, so if
22all you need are functions like `read` that don't take/return `off_t`, large
23files have always worked.
24
25Android support for `_FILE_OFFSET_BITS=64` (which turns `off_t` into `off64_t`
26and replaces each `off_t` function with its `off64_t` counterpart, such as
27`lseek` in the source becoming `lseek64` at runtime) was added late. Even when
28it became available for the platform, it wasn't available from the NDK until
29r15. Before NDK r15, `_FILE_OFFSET_BITS=64` silently did nothing: all code
30compiled with that was actually using a 32-bit `off_t`. With a new enough NDK,
31the situation becomes complicated. If you're targeting an API before 21, almost
32all functions that take an `off_t` become unavailable. You've asked for their
3364-bit equivalents, and none of them (except `lseek`/`lseek64`) exist. As you
34increase your target API level, you'll have more and more of the functions
35available. API 12 adds some of the `<unistd.h>` functions, API 21 adds `mmap`,
36and by API 24 you have everything including `<stdio.h>`. See the
37[linker map](libc/libc.map.txt) for full details.
38
39In the 64-bit ABI, `off_t` is always 64-bit.
40
41
42`sigset_t` is too small for real-time signals
43---------------------------------------------
44
45On 32-bit Android, `sigset_t` is too small for ARM and x86 (but correct for
46MIPS). This means that there is no support for real-time signals in 32-bit
47code.
48
49In the 64-bit ABI, `sigset_t` is the correct size for every architecture.
50
51
52`time_t` is 32-bit
53------------------
54
55On 32-bit Android, `time_t` is 32-bit. The header `<time64.h>` and type
56`time64_t` exist as a workaround, but the kernel interfaces exposed on 32-bit
57Android all use the 32-bit `time_t`.
58
59In the 64-bit ABI, `time_t` is 64-bit.
Elliott Hughes1d01fe82017-10-23 10:07:55 -070060
61`pthread_mutex_t` is too small for large pids
62---------------------------------------------
63
64This doesn't generally affect Android devices, because on devices
65`/proc/sys/kernel/pid_max` is usually too small to hit the 16-bit limit,
66but 32-bit bionic's `pthread_mutex` is a total of 32 bits, leaving just
6716 bits for the owner thread id. This means bionic isn't able to support
68mutexes for tids that don't fit in 16 bits. This typically manifests as
69a hang in `pthread_mutex_lock` if the libc startup code doesn't detect
70this condition and abort.