This CL is created as a best effort to migrate test targets to the new Android ownership model.
It is based on historical data from repository history and insights from git blame.
Given the nature of this effort, there may be instances of incorrect attribution. If you find incorrect or unnecessary
attribution in this CL, please create a new CL to fix that.
For detailed guidelines and further information on the migration please refer to the link below,
go/new-android-ownership-model
Bug: 304529413
Test: N/A
Change-Id: Ie36b2a3245d9901323affcc5e51dafbb87af9248
I'd assumed that it was _deliberate_ that filesystems like procfs
reported 0 here, but apparently not. Good news: this makes for a more
worthwhile test than we had previously (at least when run on a 6.7+
kernel).
Bug: http://b/321880382 (for sys_vfs_test)
Bug: http://b/319590754 (for sys_statvfs_test)
Test: treehugger
Change-Id: I0a63faa8ca359592a29d7bca1a40ecd94fd50044
(cherry picked from commit 7506c37386)
The motivation for these is long gone, and now they only serve to
distract/duplicate.
Test: treehugger
Change-Id: I28f4ea6dd02fb564a15ab23b9f70d447ddf0c090
I'd assumed that it was _deliberate_ that filesystems like procfs
reported 0 here, but apparently not. Good news: this makes for a more
worthwhile test than we had previously (at least when run on a 6.7+
kernel).
(This is the sys_vfs_test equivalent of the earlier change made to
sys_statvfs_test.)
Bug: http://b/321880382 (for sys_vfs_test)
Bug: http://b/319590754 (for sys_statvfs_test)
Test: treehugger
Change-Id: I3c6f784d1e348bf1be3a102d1dd6336c33d0b2db
(cherry picked from commit 1b48afbc66)
I'd assumed that it was _deliberate_ that filesystems like procfs
reported 0 here, but apparently not. Good news: this makes for a more
worthwhile test than we had previously (at least when run on a 6.7+
kernel).
(This is the sys_vfs_test equivalent of the earlier change made to
sys_statvfs_test.)
Bug: http://b/321880382 (for sys_vfs_test)
Bug: http://b/319590754 (for sys_statvfs_test)
Test: treehugger
Change-Id: I3c6f784d1e348bf1be3a102d1dd6336c33d0b2db
In particular: 32-bit x86 doesn't need sa_restorer either.
I still don't fully understand why arm32 and x86-64 do, so I've left the
comments in those .S files alone. I haven't (knowingly) tested
compiler-rt since we switched from libgcc (which is what the comments
refer to), but I have tested libunwindstack since we switched from
libunwind, and that does fail existing bionic tests for unwinds through
signal frames --- I just don't know why, or whether there's a better fix.
Anyway, local testing suggests that the 32-bit x86 code is vestigial, so
let's get rid of it.
Test: treehugger
Change-Id: I3e2616f736d27a8463814356e5adb52fd76a90cc
clang complains if you define a symbol and _then_ make it weak, rather
than the other way round:
/tmp/setjmp-c3c977.s:90:1: warning: sigsetjmp changed binding to STB_WEAK
.weak sigsetjmp;
^
Test: treehugger
Change-Id: Iee6b0ea456bb2e92aea810ce45f171caabaa89d2
Obviously stack MTE conflates with the stack protector test. It doesn't
conflate with heap MTE (which we're expecting to push more broadly as
part of the -eng build), and so we want to keep this test working under
heap-mte scenarios as well.
Hence, the check-if-stack-variable-is-tagged test, and only under that
case, we skip.
Test: atest bionic-unit-tests on a fullmte device (with stack MTE turned
back on and the new compiler).
Bug: 320448268
Change-Id: I2ecee8a7c46416883235bf5c4ee2de9408047829
I haven't seen this cause a problem in practice --- I noticed this while
looking at something else entirely.
Test: llvm-objdump
Change-Id: I56e38165f45554ede538a50439f8e8ffe72871c8
Kernel headers coming from:
Git: https://android.googlesource.com/kernel/common/
Branch: android-mainline
Tag: android-mainline-6.7
NOTE: The file bionic/libc/kernel/uapi/linux/usb/f_accessory.h was
deleted in the 6.7 kernel along with the functionality. However,
there is no current replacement. For now keep the file here, but at
some point when the new implementation is ready, this file will need to
be moved to the places that still need to be backwards compatible.
Test: Builds and bionic unit tests pass on raven.
Test: Able to log in to an Android GO 32 bit device.
Change-Id: Ibf5684ed140616c02bb9464bbd6422a9281a29cf
This reverts commit 4c5eeb8346 in main,
where we have the newer tzcode and so can pass the stricter test.
Bug: http://b/307680874
Test: treehugger
Change-Id: I28a6f423815655a59fb503230e50a7b618b0349a
As long as 2024Q1 is using Android 14's CTS, Android 14's CTS needs to
work with both. That doesn't make much sense for this test of a bug fix,
so just disable it.
Bug: http://b/307680874
Test: treehugger
Change-Id: Ic1bea5d0404c91279a025ac97b521f07e4d2d387
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>
