Mac compatibility

[ntjohnson1]

Closes #127

On mac with xcode apple clang is available but llvm-ar is not. Whatever version of ar mac comes with adds newline bytes to pad out the wasm32.o but that isn't parsed correctly downstream which leads to the llvm: section too large error.

The solution in this PR is to add a .pad section with 12 bytes of zeros to bring the .o to 408 bytes. Then if llvm-ar is not detected when clang is we use this padded version. An alternative is to just always use this padded version but I didn't check this anywhere else besides Mac so uncertain if different padding schemes would be unhappy with 408 bytes.

Extra Details

Padded version created via this command since copyobj seemed to not play nice with wasm. Empty.bin just 12 bytes of zeros to make the math work.

wasm-custom-section psm/src/arch/wasm32_pad.o add .pad < empty.bin

I assume you'll want to verify I didn't do anything weird on the object yourself but here were my local comparisons

hexdump -C wasm32.o > extracted.hex && hexdump -C wasm32_pad.o > original.hex && diff original.hex extracted.hex
25,27c25,26
< 00000180  3c 02 06 46 04 00 11 04  2e 70 61 64 00 00 00 00  |<..F.....pad....|
< 00000190  00 00 00 00 00 00 00 00                           |........|
< 00000198
---
> 00000180  3c 02 06 46 04                                    |<..F.|
> 00000185

llvm-readobj --sections wasm32_pad.o 

File: wasm32_pad.o
Format: WASM
Arch: wasm32
AddressSize: 32bit
Sections [
  Section {
    Type: TYPE (0x1)
    Size: 27
    Offset: 14
  }
  Section {
    Type: IMPORT (0x2)
    Size: 81
    Offset: 47
  }
  Section {
    Type: FUNCTION (0x3)
    Size: 5
    Offset: 134
  }
  Section {
    Type: CODE (0xA)
    Size: 78
    Offset: 145
  }
  Section {
    Type: CUSTOM (0x0)
    Size: 112
    Offset: 229
    Name: linking
  }
  Section {
    Type: CUSTOM (0x0)
    Size: 23
    Offset: 355
    Name: reloc.CODE
  }
  Section {
    Type: CUSTOM (0x0)
    Size: 12
    Offset: 391
    Name: .pad
  }
]

[ntjohnson1]

Ok my attempt to pack the wasmtime-cli into the dev deps failed on CI but worked locally. If you're onboard with this approach I can probably duplicate the wasm test on linux latest to run on mac just changing things in the test.yaml

[nagisa]

Hm, not sure I love this. I would rather modify wasm32.s. But that is not going to keep the file size constant in perpetuity, unfortunately.

First things first: have you tried regenerating the wasm32.o with llvm-mc from the most recent LLVM release? Maybe that would fix the macos issues transparently? At least doing it today with LLVM 19.1.7 already produces a 426-byte file (on linux.)

If its alignment and not size issue, then could approach this by adding a custom section directly from the input file, but that unfortunately does not guarantee any particular "alignment" for the file...

[ntjohnson1]

I tried llvm 19 and 20 installed via homebrew with clang -E psm/src/arch/wasm32.s | llvm-mc -o psm/src/arch/wasm32_embedded_pad.o --arch=wasm32 -filetype=obj and still only saw 389 bytes. I'm not really sure why you're seeing a larger object on linux. If you wanted to push the larger object to a branch I'm happy to try it out on Mac (but I'm fairly confident its an alignment issue based on some different padding sizes I tried).

I just pushed a change putting a fill into wasm32.s. Which definitely adds more maintenance burden, I could add a test to check the checked in object size but that still requires tuning the fill if things change.

The only other things that come to mind are:

1. See if there is another archiver mac provides by default to see if a config to cc-rs fixes things without changing the underlying object (I dug into this a decent bit before without any luck)
2. Start a discussion on the apple forums to see if there is something I'm missing or they can fix. It seems a little odd their system archiver doesn't play nice with apple clang.
3. See if build dependencies can be specified in cargo with cargo-binutils or something similar to bring along a different archiver