I would like to assemble Aarch64 armv8 Assembly on my mac and eventually run it with qemu and maybe on a real device like a raspberry pi 2 or 4 later on. I don't know how to assemble the code I'm going to write, gcc, llvm-gcc and clang don't seem to support the -arch=armv8 flag or anything similar. So I can't build for the targeted architecture, how could I achieve this?
I'm running mac os 10.14.5. I wouldn't mind finding a solution that works on a recent ubuntu version either since I have a VM for linux development.
The clang version that ships with Xcode supports -arch arm64. (Or armv7 for 32bit.)
Note that if you want to use any libraries though, they'll have to be arm64 as well. If you want, you can invoke the iOS toolchain with xcrun -sdk iphoneos clang -arch arm64 [...], but then you'll also have to pull the libraries you want off of some IPSW and stuff them into qemu.
Also note that the above will give you a Mach-O binary. For your Raspberry Pi, you'll probably want an ELF, and you'll probably want gcc rather than clang. You should be able to build both gcc and GNU binutils from source with --target as either aarch64-linux-gnu or aarch64-none-elf, depending on your goals. Yet another note: since macOS silently aliases gcc to clang and many tools depend on that, you'll probably also want to build this toolchain with something like --program-prefix=aarch64-.
Related
The official way to compile universal binaries that target Apple's new M1 processor is to use Xcode 12, which requires at minimum macOS 10.15.4. I'm currently running macOS 10.14.6 though and do not want to upgrade if I can avoid it. Is there an unofficial way to compile such a universal binary when running macOS 10.14?
This is possible to do. Of course it can't be done with Xcode on its own since Apple has long since dropped support for macOS 10.14 in its developer tools, but can be down either by compiling from the command line or using another build system like cmake or qmake.
It at minimum requires two things:
A newer macOS SDK than is officially supported in macOS 10.14, obtained from Xcode 12.2 or later
A newer version of LLVM / clang that is compatible the macOS SDK from the version of Xcode you obtained
You can actually get both things by downloading the latest release of Xcode, since as of the time of this writing (December 2022) the release of LLVM included in the latest release of Xcode (14.2) will still run in macOS 10.14.
Should that ever stop working, though, or if you would prefer not to use Xcode's release of LLVM, you can also install a newer version of LLVM and clang using MacPorts, as MacPorts continues to support older macOS releases (unlike Homebrew). The command would be sudo port install clang-15, or whatever the latest available major release of clang is.
Another option is to built and install your own copy of LLVM and clang, and the steps to do so are laid out in LLVM's documentation.
For best results, the version of LLVM should be the same major version or newer than the version of LLVM / clang included in the release of Xcode you obtained.
Once you have both of those, you can compile C, C++, or Objective-C and probably Swift with a command like:
/path/to/newer/clang \
-arch x86_64 -arch arm64 \
-isysroot /path/to/Xcode14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk \
source.m source2.cpp source3.c ...
If you installed clang using MacPorts, then its path would be something like /opt/local/bin/clang-mp-15.
In the case of only using a newer release of Xcode, you can do it like this:
/path/to/Xcode14.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang \
-arch x86_64 -arch arm64 \
-isysroot /path/to/Xcode14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk \
source.m source2.cpp source3.c ...
I've only tested this with C, C++ and Objective-C so far, and not Swift, but presumably it will work for Swift as well.
Note that if you want to target macOS 10.14, it's still necessary to avoid using parts of the macOS SDK as well as C++ and Swift features that require macOS 10.15 or later.
(It may be possible to at least make use of newer C++ features in macOS 10.14 and earlier if you build your own universal binaries of LLVM's runtimes (namely libc++ and libc++abi) from the later release of LLVM, and then compile your code with the arguments -nostdlib, statically link to libc++ and libc++abi, and then explicitly link to /usr/lib/libSystem.B.dylib. But so far I haven't managed to get an arm64 copy of LLVM's runtimes to compile in macOS 10.14.)
Short answer: No
Why?
Apple did it. There's a doc from apple here
You will have to use Xcode 12.2 and above. You must upgrade to MacOS 10.15.4+ or 11 to benifit the latest feature.
Apple brings the tool lipo to convert binaires for ARM64 and AMD64 architectures.
With Apple silicon, you can compile binaries for ARM64 and AMD64. You can debug ARM64 binaries naturally. You can debug AMD64 binaries under Rosetta translation.
With Intel x86 chips, you can compile binaries for ARM64 and AMD64. You can debug AMD64 binaries naturally. But you cannot debug ARM64 binaries under Rosetta translation.
This means Apple Silicon's ARM64 architecture can do more on MacOS. It's unfair for AMD64 chips. Tipical Apple. Hopefully someone can come out and unseals the secret Apple silicon. But I don't think apple would like to share. If Intel/AMD wake up and bring us more powerful chips which can compile/debug ARM64 binaries for MacOS, apple wouldn't be happy with their sales. For the longterm, we won't be able to do it (seemingly). Apple kicked Nvidia away years ago, now Intel, soon AMD. Mark it here. 10 years later, let's see.
I am following this tutorial on operating system development for the raspberry pi.
http://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/ok01.html
I am using a Mac, so it suggests using the Yagarto packages for assembling the code. However, they do not seem to work. I installed it multiple times to check.
I want to know if there is an alternative assembler for Mac and how to use it to create the .img file to use as the kernel for the pi.
You can use Xcode for that - if you install xcode, the "iPhone SDK" compiler is really a cross compiler for i386, x86_64 and - ARM.
${whereever_you_put_xcode}/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/as -arch armv6
will do the trick: specifically, it will execute
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/../libexec/as/arm/as
I want to start working with C++0x. I see that GCC 4.7 has a fair amount of functionality available. I already have XCode 3.2 installed in /Developer
I downloaded: http://fileboar.com/gcc/snapshots/LATEST-4.7/gcc-4.7-20110528.tar.bz2
Can I somehow compile this in /opt/gcc-4.7? How do I then work with my path so I can compile with GCC 4.7 from the command-line but have OSX use the version it needs?
OSX does not need gcc to run - the Developer tools are optional. So you only need to choose between gcc's when you compile. In Xcode you chose explicitly the gcc andin Makefiles you can set $(CC) or similar to the full path.
Alternatively rename the gcc-4.7 gcc to gcc-4.7 and use that so gcc is always the Apple one.
For ease of using multiple C++ compilers I use macports (or fink or homebrew) which will compile the compilers with the correct patches and also has a port select command to switch between the C++ compilers
This may be a very silly question, but I'm new to developing on Macs and am having a hard time with the universal binaries.
I've got an application that I'm compiling in QT Creator, which according to lipo is producing i386 architecture outputs. As I understand it, that means it is producing Mac OS X 32 bit outputs.
The application depends on two external libraries. One of these libraries I'm compiling by calling ./config first, and then make. ./config states that it is "Configured for darwin-i386-cc". However, after running make, and calling lipo on the result, the architecture is reported as x86_64.
Similarly, I have another external library. That one has no configure script, and I compile it simply by calling make. The output from this one too is x86_64.
How can I compile these two external libraries so that they produce something compatible with my application's i386 output? Better yet, how can I compile these two external libraries to produce universal libraries so I can produce a universal binary from my application that works on both 32 and 64 bit?
Also, based on the current state of the Mac world, are there any other platforms that I should be expected to target to create a proper, user-friendly Mac OS X universal binary?
Finally got it working.
In order to control the architecture of the target, I manually went in and edited the Makefiles.
For one of them, I added to the end of the line that starts with CFLAGS: -arch i386 -arch x86_64 -arch ppc
This produced a universal binary.
For the other, when I did the same thing, the compile would error out. I had to cycle through and only put one arch at a time, and then after I produced all three, I called lipo on them with the -create flag to create a universal binary.
for ./configure, you can use this:
./configure CFLAGS="-arch i386 -arch x86_64" CXXFLAGS="-arch i386 -arch x86_64" LDFLAGS="-arch i386 -arch x86_64" --disable-dependency-tracking
--disable-dependency-tracking is important or gcc/g++ will refuse to compile code.
I can't answer the main part of your question, because I always use Xcode rather than make. But as for that last part, if you support OS versions earlier than 10.6, you may need to compile for PowerPC (arch. code "ppc") as well.
I have trouble understanding the gcc compiler provided by OSX 10.6 snow leopard, mainly because of my lack of experience with 64 bits environments.
$ cat >foo.c
main() {}
$ gcc foo.c -o foo
$ file foo
foo: Mach-O 64-bit executable x86_64
$ lipo -detailed_info foo
input file foo is not a fat file
Non-fat file: foo is architecture: x86_64
However, my architecture is seen as an intel i386 type (I have one of the latest Intel Core2 duo MacBook)
$ arch
i386
and the compiler targets i686-apple-darwin10
$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
Of course, if I compile 32 bits I get a 32 bit executable.
$ gcc -m32 foo.c -o foo
$ file foo
foo: Mach-O executable i386
but I don't get the big picture. The default setup for the compiler is to produce x86_64 executables, even if I have arch saying I have a 32 bit machine (why? Core2 is 64); even if (I guess) I am running a 32 bit kernel; even if I have a compiler targeting the i686-apple-darwin platform. Why? How can they run ? Should I compile 64 or 32 ?
This question is due to my attempt to compile gcc 4.2.3 on the mac, but I am having a bunch of issues with gmp, mpfr and libiberty getting (in some cases) compiled for x86_64. Should I compile everything x86_64 ? If so, what's the target (not i686-apple-darwin10 I guess)?
Thanks for the help
The default compiler on Snow Leopard is gcc4.2, and its default architecture is x86_64. The typical way to build Mac software is to build multiple architectures in separate passes, then use lipo to combine the results. (lipo only compiles single-arch files into a multiple-arch file, or strips archs out of a multi-arch file. It has no utility on single-arch files, as you discovered.)
The bitness of the compiler has nothing to do with anything. You can build 32-bit binaries with a 64-bit compiler, and vice versa. (What you think is the "target" of the compiler is actually its executable, which is different.)
The bitness of the kernel has nothing to do with anything. You can build and run 64-bit binaries when booted on a 32-bit kernel, and vice versa.
What matters is when you link, whether you have the appropriate architectures for linking. You can't link 32-bit builds against 64-bit binaries or vice versa. So the important thing is to see what the architectures of your link libraries are, make sure they're coherent, then build your binary of the same architecture so you can link against the libraries you have.
i686-apple-darwin10.0.0 contains an x86_64 folder which is not understood by most versions of autotools. In other words, I'd say that the gcc compiler is unfortunately nothing short of a joke on Snow Leopard. Why you would bundle 32-bit and 64-bit libraries into i686-apple-darwin10.0.0 is beyond me.
$ ls /usr/lib/gcc
i686-apple-darwin10 powerpc-apple-darwin10
You need to change all your autotools configure files to handle looking in *86-darwin directories and then looking for 64-bit libraries I'd imagine.
As with your system, my mac mini says its i386 even though its obviously using a 64-bit platform, again another mistake since its distributed with 64-bit hardware.
$arch
i386
Apple toolchains support multiple architectures. If you want to create a fat binary that contains x86 and x86_64 code, then you have to pass the parameters -arch i386 -arch x86_64 to gcc. The compiler will compile your code twice for both platforms in one go.
Adding -arch i386 -arch x86_64 to CFLAGS may allow you to compile gmp, mpfr, and whatnot for multiple archs in one go. Building libusb that way worked for me.
This answer is wrong, but see comments below
The real question is... how did you get a 32-bit version of OSX? I wasn't aware that Snow Leopard had a 32-bit version, as all of Apple's Intel chips are Core 2 or Xeon, which support the x86_64 architecture.
Oh, and Snow Leopard only works on Intel chips.
Edit: Apparently Snow Leopard starts in 32-bit mode.