[all-commits] [llvm/llvm-project] ba26b5: [ORC] Mark late-claimed weak symbols as live in Ob...

[lhames via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ba26b5ef15dcbfc69f062b1aea6424cdb186e5b0
      https://github.com/llvm/llvm-project/commit/ba26b5ef15dcbfc69f062b1aea6424cdb186e5b0
  Author: Lang Hames <lhames at gmail.com>
  Date:   2022-10-29 (Sat, 29 Oct 2022)

  Changed paths:
    M llvm/lib/ExecutionEngine/Orc/ObjectLinkingLayer.cpp

  Log Message:
  -----------
  [ORC] Mark late-claimed weak symbols as live in ObjectLinkingLayer.

ObjectLinkingLayer attempts to claim responsibility for weak definitions that
are present in LinkGraphs, but not present in the corresponding
MaterializationResponsibility object. Where such a claim is successful, the
symbol should be marked as live to prevent it from being dead stripped.

(For the curious: Such "late-breaking" definitions are introduced somewhere in
the materialization pipeline after the initial responsibility set is calculated.
The usual source is the complier or assembler. Examples of common late-breaking
definitions include personality pointers, e.g. "DW.ref.__gxx_personality_v0",
and named constant pool entries, e.g. __realXX..XX.)

The failure to mark these symbols live caused few problems in practice because
late-breaking definitions are usually anchored by existing live definitions
within the graph (e.g. DW.ref.__gxx_personality_v0 is transitively referenced by
functions via eh-frame records), and so they usually survived dead-stripping
anyway. This accidental persistence isn't a principled solution though, and it
fails altogether if a late-breaking definition is not otherwise referenced by
the graph, with the result that the now-claimed symbol is stripped triggering a
"Failed to materialize symbols" error in ORC. Marking such symbols live is the
correct solution.

No testcase, as it's difficult to construct a situation where a late-breaking
definition is inserted without being referenced outside the context of new
backend bringup or plugin-specific shenanigans.

See discussion in https://reviews.llvm.org/D133452 and
https://reviews.llvm.org/D136877.