[all-commits] [llvm/llvm-project] f7d2af: [CodeGen] Emit COFF symbol type for function aliases

[Martin Storsjö via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f7d2afbac904d3605b984b5b34cfd3aec8616e63
      https://github.com/llvm/llvm-project/commit/f7d2afbac904d3605b984b5b34cfd3aec8616e63
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-01-28 (Fri, 28 Jan 2022)

  Changed paths:
    M llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
    A llvm/test/CodeGen/X86/coff-alias-type.ll

  Log Message:
  -----------
  [CodeGen] Emit COFF symbol type for function aliases

On the level of the generated object files, both symbols (both
original and alias) are generally indistinguishable - both are
regular defined symbols. But previously, only the original
function had the COFF ComplexType set to IMAGE_SYM_DTYPE_FUNCTION,
while the symbol created via an alias had the type set to
IMAGE_SYM_DTYPE_NULL.

This matches what GCC does, which emits directives for setting the
COFF symbol type for this kind of alias symbol too.

This makes a difference when GNU ld.bfd exports symbols without
dllexport directives or a def file - it seems to decide between
function or data exports based on the COFF symbol type. This means
that functions created via aliases, like some C++ constructors,
are exported as data symbols (missing the thunk for calling without
dllimport).

The hasnt been an issue when doing the same with LLD, as LLD decides
between function or data export based on the flags of the section
that the symbol points at.

This should fix the root cause of
https://github.com/msys2/MINGW-packages/issues/10547.

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