[lld] [lld][MachO] Warn on underaligned arm64 functions (PR #221636)

[Daniel Rodríguez Troitiño via llvm-commits]

================
@@ -896,6 +896,23 @@ void ObjFile::parseSymbols(ArrayRef<typename LP::section> sectionHeaders,
       return StringRef(strtab + sym.n_strx);
     };
 
+    // arm64 instructions must be 4-byte aligned, so a symbol in a code section
+    // whose guaranteed alignment is lower than that names a function that can
+    // never be executed. ld64 diagnoses this, so we do too. Note that we check
+    // each symbol rather than each subsection: an alt-entry symbol does not
+    // induce a new subsection, but it is still an entry point that has to be
+    // aligned.
+    const bool checkCodeAlign = target->cpuType == CPU_TYPE_ARM64 &&
+                                (sections[i]->flags & S_ATTR_PURE_INSTRUCTIONS);
+
+    // Mach-O reserves the 'l' and 'L' prefixes for labels that the assembler
+    // generates for its own use, such as the ltmp0 anchor it emits for each
+    // section. Those do not name functions, so ld64 does not warn about them.
+    auto isAssemblerTemp = [](const NList &sym, StringRef name) {
+      return !(sym.n_type & N_EXT) &&
+             (name.starts_with("l") || name.starts_with("L"));
----------------
drodriguez wrote:

Yes. I was just mentioning `isPrivateLabel` because I noticed it already used in the file, but I knew it couldn't be used for a more faithful version, therefore the phrase "but probably unneeded".

Anyway: I am still concerned that this is not really what Apple classic linker is doing. If you change my original example to use `ltmp1:`instead of `lmisaligned:` (or even `ltmp0`, which will be replaced by `ltmp00`, it seems), the warning is still issued. If I read the code correctly no user provided label that starts with `ltmp` will be warned about, which is not what should happen.

I am also ignoring if we want to merge at all a warning that Apple have abandoned in the modern linker, even if the warning might still be interesting to have. If I understand correctly branching instructions are implicitly multiplied by 4, so they cannot ever point to misaligned instructions, but there's some indirect branching that might be capable of ending up in those addresses. Not sure if that would be a fault and why the new Apple linker seems to ignore it.

https://github.com/llvm/llvm-project/pull/221636