The reason for using a userspace target is to use the same target as the OS we're going to run on, as it would be silly to ask even native users to install another cross-compiler. Usually whatever details that bit of the arch triplet implies can be changed with compiler flags anyway, so I'd like to keep that "lie" unless it actually causes a problem.

Seems (possibly older) versions of binutils, like 2.31.1 set the ELF arch to 'no machine' when the input format is arch-less, causing a link failure later.

The build system does create a Mach-O file natively through the toolchain, but instead builds one in the linker script, m1n1.ld, manually. AFAICS this is also a major hurdle to supporting lld or ld64, as I don't believe they support linker scripts.

As an aside @marcan: does it make sense to change the architecture to aarch64-none-elf here? m1n1 is bare-metal code, not a Linux user-space application, after all.

Seems (possibly older) versions of binutils, like 2.31.1 set the ELF arch to 'no machine' when the input format is arch-less, causing a link failure later.

This commit removes the unnecessary const on adt_getprop_copy() in both the header and the C file, since const int as a return type does not do anything different than just int, and the added const might be confusing to some.

See also the discussion in #5 "add missing const to src/adt.h".

This happened because the prototype was copied and pasted from a const void * and I changed the type without removing the const (but only one one end) :)

This commit removes the unnecessary const on adt_getprop_copy() in both the header and the C file, since const int as a return type does not do anything different than just int, and the added const might be confusing to some.

See also the discussion in #5 "add missing const to src/adt.h".

Ah, true. I just fixed the inconsistency to make it compile with clang which complained about a redeclaration with a different type. Feel free to remove the const - no hard feelings from my side ;)

That const on the return type actually doesn't do anything (at least in C), and on higher warning levels, compilers actually warn for that (-Wignored-qualifiers to be exact, it's part of -Wextra).

It doesn't do any harm, but it is a little bit inconsistent IMO, so I guess the "clean" thing to do is to remove the const in both the header and C file. It can be kept like this as well, just wanted to point out that technicality.

While watching the m1n1 bring-up stream I noticed a small copy-paste error in proxyclient.py:

The mask8() .. mask64() functions still use the P_CLEAR8 .. P_CLEAR64 opcode and don't pass the address. This commit fixes that.

Commit is untested since I don't have an M1, but the change is small enough that it most likely works.

adt_getprop_copy is defined as const in src/adt.c but not in src/adt.h

Signed-off-by: Sven Peter [email protected]

this is required to fix the following error when compiling with clang:

  CC    build/string.o
src/string.c:3:10: error: 'string.h' file not found with <angled> include; use "quotes" instead
         ^~~~~~~~~~
         "string.h"

Signed-off-by: Sven Peter [email protected]

this is required to fix the following error when compiling with clang:

  CC    build/string.o
src/string.c:3:10: error: 'string.h' file not found with <angled> include; use "quotes" instead
         ^~~~~~~~~~
         "string.h"

Signed-off-by: Sven Peter [email protected]

adt_getprop_copy is defined as const in src/adt.c but not in src/adt.h

Signed-off-by: Sven Peter [email protected]

Sorry, I was under the impression this was meant to be a working sample for the clang toolchain (saw your post on Hackernews).

While you are not using any libraries, the clang toolchain makes it hard to create a proper Mach-O binary without linking libSystem. I had thought you might have found an easy way to produce a minimal Mach-O executable

During the m1n1 bring-up stream I noticed a small copy-paste error in proxyclient.py:

The mask8() .. mask64() functions still use the P_CLEAR8 .. P_CLEAR64 opcode and don't pass the address. This commit fixes that.

Commit is untested since I don't have an M1, but the change is small enough that it most likely works.

Please don't use it for this project until people decide where it stands from a cleanroom reverse engineering standpoint

Some notes for anyone making that decision:

All programs in that repo...

• Use public llvm headers to link against a private dylib
• Runs code from that private dylib directly, rather than through public interfaces
• Call the following functions that wouldn't exist on a libLLVM.dylib compiled from public sources:
  • LLVMInitializeAGX2AsmPrinter
  • LLVMInitializeAGX2ClauseAnalyzer
  • LLVMInitializeAGX2Disassembler
  • LLVMInitializeAGX2Target
  • LLVMInitializeAGX2TargetInfo
  • LLVMInitializeAGX2TargetMC

mtl-gpu-asmcheck (but not mtl-gpu-llc) also...

• Prints internal register names compiled into Apple's private libLLVM which would not otherwise be included in binaries sent to the GPU
• Prints LLVM instruction scheduling information compiled into Apple's private libLLVM which would not otherwise be included in binaries sent to the GPU