It's especially unhelpful of us to say things like "U" given that marketing switched the public back to numbers.
Change-Id: I7fb9e30667fbf9830bc71319dcca18e92d064522
ANDROID_REL[A] need to be processed after RELR in case it contains
an IRELATIVE relocation with a resolver that accesses data relocated
by RELR.
Bug: 331466607
Change-Id: I50865e67fc1492d75324ef3cb9defef3f8b88421
GNU readelf accepts both `--header` and `--headers`, but we don't ship
that in the NDK any more, so anyone on macOS or Windows will hit this
incompatibility (even though Linux users are probably still using GNU
readelf).
Test: treehugger
Change-Id: I61eb389d4d9c0bc4f5d75ceefeb5709345299585
Since (a) they're not a README.md and (b) they moved git project
recently, it's really hard to find these docs even if you know they
exist, which no-one does.
Test: N/A
Change-Id: Ic12e47ef5eb09e692ac0974b1d33bc5dc83d1028
Update a comment in android-changes-for-ndk-developers.md about the
removed debug.ld.greylist_disabled system property.
Update language to comply with Android's inclusive language guidance
#inclusivefixit
See https://source.android.com/setup/contribute/respectful-code for reference
Bug: http://b/162536543
Test: bionic-unit-tests
Change-Id: I760ee14bce14d9d799926c43d2c14fd8ffbc6968
Until now we've only supported RELR with our own OS-private-use
constants. Add support for the official numbers (while maintaining
support for the historical numbers).
Add tests to ensure we continue to support both indefinitely.
We can't yet flip the build system over to using the official constants
because the old GNU binutils objcopy we still use in most cases (for the
mini-debug section) only supports the historical constants.
Bug: http://b/147452927
Test: treehugger
Change-Id: If214fce7fade4316115947e90b78ab40864b61f2
Useful for testing whether apps have actually stopped using greylisted
libraries even if they still have references to them in their apk to support
old Android releases but also haven't bumped their targetSdkVersion yet.
Since we already have two expensive __system_property_get calls and this
would add a third, optimize two (but leave the third since it's not
obviously amenable to optimization). None of this matters for user builds,
but I don't want userdebug/eng to have distractingly different performance.
(cherrypick of 7933bec2872aa1c3430149c7649726333c0ac9d8.)
Bug: http://b/36106661
Test: ran "can you escape 5" with and without this property
Change-Id: Id9a804695c1dca9b4be2ebd0e72f01817bb13cba
I don't think we're getting any value from more dupes of the same dodgy
middleware, and I worry that we're hiding other, more subtle, compatibility
issues behind this one.
Test: bionic tests
Change-Id: I556cf36eac96c90976bae32621d1c133bbb8fcc7