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
Related
I'm trying to compile and link an assembly file to an executable with NASM and the standard LD linker on my MacBook Air M1. I have no problems with getting the .o file, but if I want to link it with LD, it throws that error:
ld: file not found: elf_i386
Command:
ld -m elf_i386 -s -o hello hello.o
What do I have to change?
Those are options for GNU ld on x86 Linux. (Note the ELF part of the target object-file format, and the i386). MacOS uses the MachO object-file format, not ELF, and apparently their ld takes different options.
Also, MacOS hasn't supported 32-bit x86 for a few versions now, so an M1 mac with an AArch64 CPU definitely can't run 32-bit x86 executables natively.
So get an emulator for a 32-bit Linux environment if you want to follow a tutorial for that environment, or find a tutorial for AArch64 MacOS. Or possibly x86-64 MacOS which should still work transparently thanks to Rosetta, but make sure single-step debugging actually works. That's an essential part of a development environment for learning asm.
Assembly language is not portable at all, you need a tutorial for the OS, CPU-architecture, and mode (32-bit vs. 64-bit) that you're going to built in. Don't waste your time trying to port a tutorial at the same time you're learning the basics it's trying to teach. You'd have to already know both systems to know which parts of the code and build commands need to change.
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 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-.
I am trying to use msys powerpc-eabispe-gcc compiler on windows to compile a simple helloworld.cpp program, inorder to generate an elf for powerpc architecture, but I am getting "c++ compiler not installed on this system" error. The bin folder of powerpc-eabispe contains all the exe's, I dont understand why then I get this error??
I used MinGW command prompt to run this command: powerpc-eabispe-gcc.exe -o hello hello.cpp
You need to install the toolchain for the architecture you are targeting.
Search for "cctools" / "binutils" / "crosstools" or "ppc cross-compile environment".
You can also take a look at:
Building and Testing gcc/glibc cross toolchains (This will probably work)
Host/Target specific installation notes for GCC (search powerpc in the page)
However, I would encourage you to try this on a linux or on a mac computer. There are far more resources & docs available on the web for cross-compilation on these platforms.
I'm using Xcode 3.2.3 on Mac OS X 10.6.6 on a Mac Pro to build revision 5fd480ef577f of GrowlTunes from the growl-development repository.
With a clean build from a virgin checkout, this is what I get:
% gdb build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes
GNU gdb 6.3.50-20050815 (Apple version gdb-1469) (Wed May 5 04:41:34 UTC 2010)
[blah blah blah]
This GDB was configured as "--host=x86_64-apple-darwin --target=powerpc-apple-darwin"...Reading symbols for shared libraries ......... done
(gdb) run
Starting program: /Volumes/RAM Disk/growl-development/Extras/GrowlTunes/build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes
Don't know how to run. Try "help target".
When I try it in Xcode, it apparently does some internal test that fails, because it doesn't even list GDB as an option. Since there are no other debuggers (in this version of Xcode) for Cocoa applications, the pop-up menus related to debugging in the target Info window are empty, and attempting to run the app does nothing—the Run button switches back to being the Run button immediately.
The target is built for 32-bit PowerPC and 64-bit Intel:
% file build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes
build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes: Mach-O universal binary with 2 architectures
build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes (for architecture ppc7400): Mach-O executable ppc
build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes (for architecture x86_64): Mach-O 64-bit executable x86_64
I can run it directly, either from the terminal or from Finder, but that doesn't help me step-by-step debug.
This isn't a cross compilation scenario; I mean to run the 64-bit Intel architecture, which is my machine's native architecture, not the PowerPC architecture.
I'm guessing this is some build misconfiguration somewhere in the project, but I've no clue what or where. Any suggestions?
Workaround from a contact of mine:
gdb -arch x86_64 build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes
I'd still appreciate a solution that would enable me to run/debug the app in Xcode.
Switching the order of the architectures in the relevant build setting fixed the problem both in gdb and in Xcode. This is a lame solution, and I'd still welcome a better one, but at least it works.
At gdb prompt, try 'set arch x86_64' or 'set arch i386:x86-64' (without quotes of course; I am a total newbie with gdb, I am lurking for solutions for other problems)