Comments (10)
R_ARM_COPY implies text-relocations in the executable and it is indeed not supported for apps targeting sdk version M and later.
I am a little bit fuzzy on how object relocations turn into R_ARM_COPY, if I had to guess I would say this is because D generated a file that lead to this relocation in final elf-file.
Does your code have inline assembly? If so that might be the source of the problem and this link could help with it: https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide
If not - I would try (1) checking if ld.gold does the same thing and (2) asking D compiler team about it.
from ndk.
Here's the thing, the exact same object files produce an executable without that relocation when I use older or newer versions of ld.bfd. That says to me that it is a bug in the linker, nothing to do with D. As for ld.gold, I noted that it doesn't have the issue, but that I need ld.bfd because it has linker scripts that keep ELF section ordering, whereas gold just reorders them any way it likes.
from ndk.
This definitely sounds like a bfd bug.
from ndk.
I've packaged up some test objects to try out, along with the resulting executables produced by the older ld.bfd from NDK r10e and the newer one from r11. Here are the commands used to produce test.break and test.work from the given test.o and libdruntime-ldc.a:
/opt/ndk-r11/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -Wl,-z,nocopyreloc --sysroot=/opt/ndk-r11/platforms/android-9/arch-arm -lgcc -gcc-toolchain /opt/ndk-r11/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 -target armv7-none-linux-androideabi -no-canonical-prefixes -fuse-ld=bfd -Wl,--fix-cortex-a8 -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--warn-shared-textrel -Wl,--fatal-warnings -mthumb -lc -lm test.o lib/libdruntime-ldc.a -o test.break
/opt/android-ndk-r10e/toolchains/llvm-3.6/prebuilt/linux-x86_64/bin/clang -Wl,-z,nocopyreloc --sysroot=/opt/ndk-r11/platforms/android-9/arch-arm -lgcc -gcc-toolchain /opt/ndk-r11/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 -target armv7-none-linux-androideabi -no-canonical-prefixes -fuse-ld=bfd -Wl,--fix-cortex-a8 -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--warn-shared-textrel -Wl,--fatal-warnings -mthumb -lc -lm test.o lib/libdruntime-ldc.a -o test.work
test.o is compiled from this small D file that simply calls putc on stdout:
import core.stdc.stdio;
void main() { putc('a', stdout);}
libdruntime-ldc.a is the D runtime library, which contains core.stdc.stdio
that references __sF
.
from ndk.
FYI, I've asked our binutils guy to take a look at this. Sounds like he has an idea of the patches that need to be cherry-picked, so should be doable for r12.
from ndk.
Thanks, looking forward to that, I'll just use the older bfd linker in r10e for now.
from ndk.
Hi, joakim-noah and Dan,
First of all, for the 2 command lines you aforementioned (thanks for providing reproducible commands), actually, they are using exactly the same binutinls binary - "/opt/ndk-r11/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9/../../../../arm-linux-androideabi/bin/ld.bfd". Because of the fact both '-gcc-toolchain' point to the same location.
So it's not a regression in binutils.
Secondly, the reason for "regression" is in clang. The earlier (ndk-r10) clang, while calling ld.bfd, passes a '-pie', while the newer one 'ndk-r11' clang not. You can observe this by adding '-v' right after clang.
Thirdly, this change is quite dubious - whether or not to add '-pie' by default affects the final binary in multiple ways. @DanAlbert is this dropping '-pie' intentional?
I pasted the 2 commands below for reference
Command generates broken binary -
/opt/ndk-r11/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -Wl,-z,nocopyreloc \
--sysroot=/opt/ndk-r11/platforms/android-9/arch-arm -lgcc \
-gcc-toolchain /opt/ndk-r11/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 \
-target armv7-none-linux-androideabi -no-canonical-prefixes -fuse-ld=bfd \
-Wl,--fix-cortex-a8 -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now \
-Wl,--warn-shared-textrel -Wl,--fatal-warnings -mthumb -lc -lm test.o \
lib/libdruntime-ldc.a -o test.break`
Command generates good binary -
/opt/android-ndk-r10e/toolchains/llvm-3.6/prebuilt/linux-x86_64/bin/clang \
-Wl,-z,nocopyreloc --sysroot=/opt/ndk-r11/platforms/android-9/arch-arm -lgcc \
-gcc-toolchain /opt/ndk-r11/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64 \
-target armv7-none-linux-androideabi -no-canonical-prefixes -fuse-ld=bfd \
-Wl,--fix-cortex-a8 -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now \
-Wl,--warn-shared-textrel -Wl,--fatal-warnings -mthumb -lc -lm test.o \
lib/libdruntime-ldc.a -o test.work
from ndk.
@shenhanc78, thanks for looking into this issue. You're right: that flag is the difference and the linker used is actually the same one from r11 with both command invocations. It appears Dan took out PIE by default from clang last year, and it was added to the makefiles instead.
I extracted the flags I was using from Android API 9, by running ndk-build V=1
on the since-removed test-libstdc++ NDK sample executable, because I wanted to have as broad Android support as possible. However, that's why I missed the -fPIE -pie
flags that the NDK build scripts add for any executables compiled against Android API 16 or above, when PIE began being supported.
I will use those PIE flags instead, as the market share of Android API 15 and older is small.
from ndk.
First of all, for the 2 command lines you aforementioned (thanks for providing reproducible commands), actually, they are using exactly the same binutinls binary - "/opt/ndk-r11/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9/../../../../arm-linux-androideabi/bin/ld.bfd". Because of the fact both '-gcc-toolchain' point to the same location.
So it's not a regression in binutils.
@joakim-noah: can you comment on that? Was that an error when copying the information into the bug, or is that right?
@shenhanc78: Dropping -pie
by default was intentional; Android did not support PIE executables until android-16 (Jelly Bean). @joakim-noah: if you're building executables for pre-JB with -pie
, they won't run.
from ndk.
@joakim-noah: can you comment on that? Was that an error when copying the information into the bug, or is that right?
I did comment on it above, "You're right: that flag is the difference and the linker used is actually the same one from r11 with both command invocations." I had tried to make the command-lines as identical as possible by using the same --sysroot
and -gcc-toolchain
from NDK 11, with only the compiler different.
I didn't know that meant they'd use the same linker too, I only checked after @shenhanc78 mentioned it and he's right. The only difference is what he said: the old clang 3.6 in NDK r10e was passing the -pie
flag to the linker by default, whereas the new clang 3.8 in NDK r11 isn't. I should have checked this myself before filing the issue.
@joakim-noah: if you're building executables for pre-JB with -pie, they won't run.
Yes, I know, that's fine with me. Apparently, they only ever ran for me on 4.1 and above because clang was passing -pie
by default before.
I suppose this issue shows that some other flag will now have to be passed to the linker if you want to support Android APIs before 16, ie non-PIE? You could change the topic to that if you like.
from ndk.
Related Issues (20)
- [BUG] Clang++ Segmentation fault when building AOSP branch android-14.0.0_r35 HOT 3
- [Bug]: error: ran out of registers during register allocation HOT 17
- Android builds with unity fail: "Library\Bee\artifacts\Android" HOT 4
- [FR] push/pop required policies in cmake toolchain file HOT 16
- [DOC] Clarification on 16k page size support for x86_64 devices HOT 3
- [DOC] `system_fonts.h` HOT 7
- [Bug]: Lambda segfaults in Clang HOT 11
- [FR] Official NDK release for Linux arm64 HOT 1
- [Bug]: fatal error: error in backend: Cannot select: 0x10ba8ace0: nxv4f32 = BUILD_VECTOR 0x133163a90, 0x1330f4800, 0x133108d20, 0x1248b9e60 HOT 6
- [BUG] Compilation Error with std::execution in C++17 HOT 3
- [BUG] CLEAR_VARS does not clear LOCAL_STRIP_MODE variable HOT 2
- [Bug]: Android NDK r27 rc2 miscompiles code with inderect gotos HOT 13
- [Bug] NDK's openmp test crashing on x86 with latest LLVM update HOT 4
- Please provide maintainable list of NDK codename-revision pairs HOT 3
- [Bug]: clang compile with -D_FORTIFY_SOURCE=2 -Dstatic= cause undefined symbol: snprintf HOT 7
- [BUG] android-ndk-r26c use -pg ld.lld: error: undefined symbol: _mcount HOT 7
- [Bug]: Compiler Crash HOT 5
- [FR] support libclang? HOT 1
- [BUG] investigate odd find_package behavior HOT 3
- [BUG] NDK 27 no longer supports passing in `CMAKE_SYSTEM_PROCESSOR` to CMake to set the arch HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ndk.