• resubmit to catch parent-diff dependence

• revise according to review feedback

• final alignment & comment tweaks

• expand some comments, improve some alignment expressions

• wrap #if defined(__APPLE__) around <sys/mman.h> and msync()

• revise according to review feedback

I won't complain if someone accepts the diff! ;)

• set version as ... s/0x20400/CS_SUPPORTSEXECSEG/

• revise according to review feedback

• revise according to review feedback

• import code signing structs & enums into llvm/include/llvm/BinaryFormat/MachO.h

In D96164#2563794, @tschuett wrote:

https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/BinaryFormat/MachO.h
seems to be inspired by the Apple headers. It is not a one-to-one copy.

I could use some advice regarding import of the the Apple C (not C++) header cs_blobs.h:

• Some struct decls contain zero-length array members as offset markers. These are invalid C++, and LLD doesn't need them.
• Some struct decls contain flexible array members. These are invalid C++, and LLD doesn't need them.
• Some flag bit sets are specified via sequences of #define. LLVM prefers enum.
• All struct decls have __attribute__((aligned(1))). LLD does not need or want these.
• Struct definition pattern is typedef struct __TAG { ... } NAME; C++ prefers struct NAME { ... };
• The linter complains about case style for struct names.

• Invalidate signature-verification cache after writing hashes.
• replace CodeSigningTypes.h with augmented cs_blobs.h
• use appropriate constant symbols from cs_blobs.h rather than magic integers

In D96164#2562701, @gkm wrote:

In D96164#2562655, @thakis wrote:

Re the copy stuff: See the CL desc and openradar link in https://reviews.llvm.org/rGba3bc2fd41b8428904fc779e353d3769074d8982

That is good to know. This case differs: LLD is not overwriting an existing file, so is not reusing an vnode. There is something funky in FileOutputBuffer, which creates the LLD output file via mmap(2).

In D96164#2562655, @thakis wrote:

Re the copy stuff: See the CL desc and openradar link in https://reviews.llvm.org/rGba3bc2fd41b8428904fc779e353d3769074d8982

In D96164#2562311, @tschuett wrote:

Does codesign.go make any differences?

In D96164#2562426, @cynecx wrote:

Hmm, this is indeed very weird. I have seen "similar" behavior with codesign. codesign can actually fail. The only way to "get it working" again is to copy the file and codesign the copy, then replacing the original file (a different inode fixes codesigning).

Does the segfault happen with each linking step?

• remove SHA256, which is added separately in D96540

• drop the fork+exec of /usr/bin/codesign and rewrite in C++

In D96164#2555222, @cynecx wrote:

Perhaps this might help: SHA256 impl for LLVM. This is based on botan's sha256 implementation and mimics the current SHA1 api design. It should be compatible with LLVM's license since it's based on botan's implementation, which is BSD-2 licensed.

In D96164#2546586, @thakis wrote:

I think codesign -s also doesn't set the magic "codesigned by linker" bit that makes strip etc work better (and if doesn't work in cross builds from non-mac hosts). I kind of agree that putting this in as is isn't super useful.

• Make RelocAttrBits::LLVM_BITMASK_LARGEST_ENUMERATOR adequate to escape assertions.

• rebase

• rebase & remove incomplete+failing test (will add later)

In D96164#2547480, @smeenai wrote:

In D96164#2547390, @thakis wrote:

LLVM tries to not depend on external libraries if possible. Given that sha256 isn't that much code (https://golang.org/src/crypto/sha256/), just adding a fresh implementation of it (to lld/MachO for now) is probably the way to go.

Agreed. There's some prior art here too ... LLVM has a SHA1 implementation in llvm/include/llvm/Support/SHA1.h and llvm/lib/Support/SHA1.cpp. That was adapted from an existing public-domain implementation, and we could do the same here (find a SHA256 implementation with a license that allows it to copied into LLVM).

In order to perform ad-hoc codesign, I will need to compute sha256 of the program's pages. I see no other part of LLVM that uses a sha256 library. What library should I use?

In D96164#2546549, @int3 wrote:

hm is this that much more convenient than invoking codesign after LLD finishes running in whatever build we're testing?

• nit + rebase

• revise according to review feedback

@compnerd: I am uncertain how to structure a good test. A good test for satisfactory load-command order is already implicit: lld-linked programs don't run on ARM64 macOS otherwise.

• remove PageSize change, which is premature.

• rebase to see if seemingly-unrelated test failures resolve.

@int3 @smeenai
Regarding test failures x64 debian > libarcher.races ... These look unrelated to anything I have done in this diff, but looks can be deceiving.

• revise according to review feedback
• rewrite prepareSymbolRelocation() and resolveSymbolVA() as reloc-attribute-driven rather than target-specific

I also completed the TODO(gkm): hoist into target-independent code driven by RelocAttrBits refactors for prepareSymbolRelocation() and resolveSymbolVA()

@compnerd, I updated the title and summary as requested.

• revise according to review feedback

• revise according to review feedback

Pulling this back from review ... Not ready for prime time.

• Update according to refactored reloc handling

• Pare CHECK lines to the essentials. Add comments to the test: purpose, plus rationale for binary input.

@thakis, that's a bug. There is no reason to deviate from ld64.

@MaskRay?

• add test case

I fixed the clang-tidy failures before landing. Unfortunately, I neglected to update the diff with the final version, which is why you see the notice that I landed with ongoing build failures. Oops. :(

• rewrite encoding-index maps to use .find() rather than .lookup() so we can remove the crufty size_tx

Awesome! Thank you @cchen15 !

This diff breaks git source trees on case-insensitive filesystems, such as on macOS.
I did this on Linux, which is case-sensitive:

$ find . |fgrep -i llvm/test/DebugInfo/X86/DIModule.ll
./llvm/test/DebugInfo/X86/DIModule.ll
./llvm/test/DebugInfo/X86/dimodule.ll

On a case-insensitive filesystem, these names collide and one overwrites the other, yeilding a tree with irreconcilable conflicts.

• revise according to review feedback