4 ms·

That's not a lack of support, it's just LLD, the LLVM linker, being broken. I hear LLD for Mach-O is being worked on again, after a long period of stagnation w

by comex 6y ago

That's not a lack of support, it's just LLD, the LLVM linker, being broken. I hear LLD for Mach-O is being worked on again, after a long period of stagnation where it was sort of but not fully working. But the default linker on Apple platforms is still ld64.

tyingq 6y ago
I'd give them a little more grace. It sounds like the M1 requires a different approach than other ARMV7 cpus, and that fact wasn't documented. Mimalloc had to trudge through the same thing: https://github.com/microsoft/mimalloc/issues/343 https://github.com/microsoft/mimalloc/issues/343
- comex 6y ago
  Well, in theory, Zig doesn't need to care about the specific approach. In the LLVM IR that Zig produces, thread-local variables are still handled as an abstract "thread_local" flag on global variables. The platform-specific parts are handled by a combination of the IR-to-native-object-file translation done by LLVM, and the linking step. If both of those worked correctly, thread locals would "just work" on M1. The problem is that (a) Zig uses LLD for linking and (b) LLD is buggy. I'm not surprised that Zig is using LLD. Zig wants to be fully self-contained, able to cross-compile for any supported platform without requiring the user to install a toolchain for that platform. And they already use LLVM for code generation, so LLD for linking is the natural choice. It's a beautiful vision - really. Toolchain installation sucks. And the stuff they're doing with processing and bundling OS C headers [1] is quite innovative. It's just that using LLVM for everything is not a reality for Apple platforms yet. Hopefully it will be soon, once Apple whips LLD into shape. Edit: mimalloc is different; it reimplements thread-local storage by hand, using `asm` statements, rather than using native `thread_local` variables, presumably because the latter can be slow. [1] https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
  - shawnz 6y ago
    I think the parent poster is saying that LLD needs to take a different approach, not Zig. But it wasn't previously known what approach that would need to be, since M1 does it differently than other ARM CPUs. Therefore there's no expectation that LLD could have gotten it right.
    - refulgentis 6y ago
      LLVM/Clang were essentially born and stewarded by Apple, it's somewhat odd, to say the least, that they didn't patch LLD on day 1 with the Xcode release that supports M1.
      - ndesaulniers 6y ago
        This assumes that LLD has been around much longer than it has. Apple first sponsored development of LLVM, before clang or LLD existed. Then they sponsored clang development. LLD came much later. I believe Rui created LLD at Google with an intention of linking Chrome on Windows. That was a very different use case than what Apple had in mind. Eventually LLD abstracted the target object file, could link ELF executables, and had a good design for furthering support for mach-o. Facebook is developing that in LLD surely to support linking their iOS app much faster. Apple remains disinterested from what I can tell.
        refulgentis 6y ago
        thank you, learned a lot :) (I had assumed lld came with the llvm/clang switchover back in...ios 5?)
  - ndesaulniers 6y ago
    > LLD is buggy. While certainly not bug free, you may be overstating things. > once Apple whips LLD into shape Pretty sure it's engineers at Facebook contributing mach-o fixes to LLD, not Apple. Apple is happy with their linker ld64.
    - 6y ago
- marcan_42 6y ago
  This has nothing to do with the M1 CPU itself, it's just about how Apple implemented things in macOS. Linux doesn't care.
fomine3 6y ago
Is LLD on Mach-O considered stable? https://github.com/ziglang/zig/pull/8282 https://github.com/ziglang/zig/pull/8282 https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/mac_lld.md https://chromium.googlesource.com/chromium/src/+/refs/heads/...

by comex 6y ago

tyingq 6y ago

I'd give them a little more grace. It sounds like the M1 requires a different approach than other ARMV7 cpus, and that fact wasn't documented. Mimalloc had to trudge through the same thing: https://github.com/microsoft/mimalloc/issues/343 https://github.com/microsoft/mimalloc/issues/343

comex 6y ago
Well, in theory, Zig doesn't need to care about the specific approach. In the LLVM IR that Zig produces, thread-local variables are still handled as an abstract "thread_local" flag on global variables. The platform-specific parts are handled by a combination of the IR-to-native-object-file translation done by LLVM, and the linking step. If both of those worked correctly, thread locals would "just work" on M1. The problem is that (a) Zig uses LLD for linking and (b) LLD is buggy. I'm not surprised that Zig is using LLD. Zig wants to be fully self-contained, able to cross-compile for any supported platform without requiring the user to install a toolchain for that platform. And they already use LLVM for code generation, so LLD for linking is the natural choice. It's a beautiful vision - really. Toolchain installation sucks. And the stuff they're doing with processing and bundling OS C headers [1] is quite innovative. It's just that using LLVM for everything is not a reality for Apple platforms yet. Hopefully it will be soon, once Apple whips LLD into shape. Edit: mimalloc is different; it reimplements thread-local storage by hand, using `asm` statements, rather than using native `thread_local` variables, presumably because the latter can be slow. [1] https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
- shawnz 6y ago
  I think the parent poster is saying that LLD needs to take a different approach, not Zig. But it wasn't previously known what approach that would need to be, since M1 does it differently than other ARM CPUs. Therefore there's no expectation that LLD could have gotten it right.
  - refulgentis 6y ago
    LLVM/Clang were essentially born and stewarded by Apple, it's somewhat odd, to say the least, that they didn't patch LLD on day 1 with the Xcode release that supports M1.
    - ndesaulniers 6y ago
      This assumes that LLD has been around much longer than it has. Apple first sponsored development of LLVM, before clang or LLD existed. Then they sponsored clang development. LLD came much later. I believe Rui created LLD at Google with an intention of linking Chrome on Windows. That was a very different use case than what Apple had in mind. Eventually LLD abstracted the target object file, could link ELF executables, and had a good design for furthering support for mach-o. Facebook is developing that in LLD surely to support linking their iOS app much faster. Apple remains disinterested from what I can tell.
      - refulgentis 6y ago
        thank you, learned a lot :) (I had assumed lld came with the llvm/clang switchover back in...ios 5?)
- ndesaulniers 6y ago
  > LLD is buggy. While certainly not bug free, you may be overstating things. > once Apple whips LLD into shape Pretty sure it's engineers at Facebook contributing mach-o fixes to LLD, not Apple. Apple is happy with their linker ld64.
  - 6y ago
marcan_42 6y ago
This has nothing to do with the M1 CPU itself, it's just about how Apple implemented things in macOS. Linux doesn't care.

fomine3 6y ago

Is LLD on Mach-O considered stable? https://github.com/ziglang/zig/pull/8282 https://github.com/ziglang/zig/pull/8282 https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/mac_lld.md https://chromium.googlesource.com/chromium/src/+/refs/heads/...