I have tried -mthumb, it looks like the sources just get compiled for ARM. I have tried triple --target=thumbv7-linux-gnueabihf, but the build system just skips compiling the project. I know they somehow compile for Thumb-only target with the same build system (perhaps configuring in a different way, different target, options etc), but I can't reproduce so far the problem where my ARM assembly fails to compile on a Thumb-only CPU.
I've looked through gcc options for Thumb and got only the above ideas.
EDIT: it seems they compile for Thumb-only CPU on a Thumb-only CPU, so it is automatically selected as the default target. But I am cross-compiling from x86_64-Windows to ARM-Linux (and I want Thumb-Linux).
EDIT2: more specifically, I am trying to reproduce the following error in my assembly file:
Error: attempt to use an ARM instruction on a Thumb-only processor -- push {r1-r3,lr}
Related
GCC is a compiler collection that generates machine code from different programming languages. For that you have to compile the compiler to run on your architecture and operating system. But you also have to define what kind of machine code and file format is generated.
Now my questions:
Is the output file of GCC only configurable at compilation time of GCC?
And can GCC be compiled so that it supports multiple architectures and file formats?
gcc and binutils are designed to build for one architecture/family at a time. So if you build them as a cross compiler for ARM then you cannot build mips, but you can have multiple/many installations so you can also build one to target mips and use that one.
clang/llvm if when you build you don't tell it not to it will build a tool for all targets it knows. This tool will get you up to the object level for any of the supported targets with the one tool, but linking is another story you need to tell it to builds its linker (and then I don't remember if the linker will support any target or one). You can use binutils to assemble/link for clang/llvm (and then you definitely have a single target assembler/linker).
I have some C++ code using NEON intrinsics. From what I have read, all you need to do is include arm_neon.h to your project.. And then I read that this arm_neon.h header is not actually readily available to you automatically, you have to get it from the web. So I found and added this version to my project:
http://clang.llvm.org/doxygen/arm__neon_8h-source.html
In my project's prefix.pch I added:
#import "arm_neon.h"
And when I try to build on my iPhone6 device (I am not using the simulator), I get a billion errors inside the arm_neon.h file:
Can anyone please explain to me what I am missing here?
You've been misinformed about being able to pick up an arm_neon.h from the Internet. Generally the header is not just compiler specific, but compiler version (even compiler revision) specific. For GCC it relies on a number of compiler built in function calls, and from your screenshot of Clang the same holds there. As you'd expect, if the name of these internal-only functions changes, the header will fail to compile.
What surprises me is that you're unable to use an include of whichever arm_neon.h ships with your build environment. The only thing I can think of that would cause this is the build command trying to build for x86_64 (for the simulator) but you say this isn't what is happening. It might be worth checking your build settings one more time.
If you're still not getting anywhere, remember that arm_neon.h is sometimes considered as a system header, so in C++ you might need to #include <arm_neon.h> rather than #include "arm_neon.h" to get the compiler to search the system paths.
For some reason the compile speed of LLVM is extremely slow on my Mac, and based on my observation most of the time is spend on compiling the different target in llvm/lib/Target.
However, the only target I need is X86, so I'm wondering is there a way to specify the target I want to compile so that the LLVM will only compile that target and save a lot of time?
You can pass -DLLVM_TARGETS_TO_BUILD=X86 to the initial cmake invocation.
I am building Go code that uses CGo heavily and this code must be compiled into a shared or static library (static is highly preferred). (code for reference)
It all works just fine on Linux and Mac, but on Windows it fails on linker stage either saying that all 4 modes (c-shared, shared, c-archive, archive) are not available or if invoke go tool link -shared manually complains about missing windows specific instructions.
My understanding is that all I need to build usable lib.a is to compile everything I will use into object files (*.o) and then put it through ar to produce usable static library.
Now the question is whether I can completely skip Go's linker and based on prepared .o files create .a manually?
How would I go about doing that if that is even possible?
Looks like gcc on windows is unable to automatically discover necessary shared libraries. The problem was caused by GCC and not by Go.
Although for compiling Go I had to use self-compiled master tip as current release (1.6.2) does not support shared/static libraries on windows/amd64.
Manually feeding gcc with each shared library (ntdll, winmm etc) in default location (C:\Windows\SysWOW64) has fixed the problem.
I'm working on a project focusing on the MIPS32 arch (little endian). The vendor gave me a GNU toolchain to compile my project targeting their embedded Linux version and everything works just fine. It's a GCC+Linux+uClibc toolchain.
However, recently I've needed to add some features to my uClibc build, so I've tried to replicate the vendor's toolchain in my own box.
Everything worked fine with the help of crosstool-ng, but when I try to compile my project, I get strange linker warnings all over the place:
warning: linking abicalls files with non-abicalls files
From what I researched, these are pretty serious warnings. Analyzing my object files with readelf will give me almost identical output. There are no .abicall section anywhere in those files. This holds true for both my project's object files to my toolchain's ones.
What could be wrong here? I don't even know where to start debugging this.