[all-commits] [llvm/llvm-project] 062c66: [lld/mac] With -demangle, strip leading _ from non...

[Nico Weber via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 062c660dbfa81a742440cec49446fe81fc7d0114
      https://github.com/llvm/llvm-project/commit/062c660dbfa81a742440cec49446fe81fc7d0114
  Author: Nico Weber <thakis at chromium.org>
  Date:   2022-10-04 (Tue, 04 Oct 2022)

  Changed paths:
    M lld/MachO/Symbols.cpp
    M lld/test/MachO/invalid/duplicate-symbol.s
    M lld/test/MachO/invalid/undefined-symbol.s
    M lld/test/MachO/undef-suggest-extern-c.s
    M lld/test/MachO/undef-suggest-extern-c2.s

  Log Message:
  -----------
  [lld/mac] With -demangle, strip leading _ from non-mangled names

For

    void f();
    int main() { f(); }

`lld -demangle` now produces

    ld64.lld: error: undefined symbol: f
    >>> referenced by path/to/main.o:(symbol main+0x8)

instead of

    ld64.lld: error: undefined symbol: _f
    >>> referenced by path/to/main.o:(symbol _main+0x8)

previously. (Without `-demangle`, it still prints `_f` and `_main`.)

This does *not* match ld64's behavior, but it does match e.g. lld/COFF's
behaviour.

This is arguably easier to understand: clang prepends symbol names with `_`
on macOS, so it seems friendly if the linker removes it again in its
diagnostics. It also makes the `extern "C"` insertion diagnostics we added
recently look more self-consistent.

Differential Revision: https://reviews.llvm.org/D135189