[PATCH] D132345: [JITLink] Add support for symbol aliases.

[Lang Hames via Phabricator via llvm-commits]

lhames created this revision.
Herald added subscribers: jeroen.dobbelaere, StephenFan, mgrang, hiraditya.
Herald added a project: All.
lhames requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

MachO, ELF and COFF all include support for symbol aliases -- alternative names
for existing symbols. They tend to be rare (JITLink has survived without them
until now), but we need to be able to support them where they are used.

This commit introduces alias support to the LinkGraph by adding new operations
on the Symbol class (and associated helpers in the LinkGraph). By representing
aliases as Symbol objects we avoid introducing a new abstraction and maintain
the property that Edges point at Symbols.

Aliases can be added using the addAlias method. Aliases have a target Symbol
(the symbol that they alias), Name, Size, and Linkage. By default aliases take
their Scope, Liveness, and Callability from the target symbol, though these
properties can be modified independently after they're created.

New LinkGraph operations are introduced to support inspecting aliases:

- isAlias -- Returns true for symbols that are aliases, false otherwise.

- getAliasTarget -- If the given symbol is an alias then returns the symbol that it is an alias for, otherwise returns null.

- getAliasRoot -- Returns the "real" symbol that the given symbol points to, through any number of intermediate aliases (returns the given symbol itself if it is not an alias).

- aliases_empty, aliases_size, aliases_begin, aliases_end, aliases -- Standard container-like operations on the list of aliases for the given symbol.

- alias_tree_begin, alias_tree_end, alias_tree -- Provides iteration over the tree of aliases rooted at the given symbol. E.g. give the alias relationships [ A -> B, B -> C, D -> C ], alias_tree(C) will return the sequence [C, B, A, D]. Iteration with alias_tree is useful because it allows clients to write simple loops over all aliases (immediate and transitive) of a given symbol to update them.

- applyToAliases -- Iterates over all aliases of a given symbol according to an AliasOperationPolicy argument, which is SubTree (operate on all aliases in the tree rooted at the given symbol), WholeTree (operate on all aliases of the tree rooted at the alias root of the given symbol, i.e. *all* aliases including parents and siblings), None (do not apply the operation to any Symbols other than the given one), or AssertNoAlias (an optimized version of None that strips any checks for alias info). The applyToAliases method is used in the updated implementation of several existing LinkGraph methods.

In addition to the new operations, several existing operations have had an
AliasMovePolicy argument added, which controls how aliases of the given Symbol
are handled when moving the given Symbol within the LinkGraph, or removing it
from the LinkGraph. The AliasesBecomeReal policy will cause any aliases to
become "real", disconnecting them from the symbol being operated on and
allowing them to keep their existing properties and location. The SubTree
policy will cause the move/removal to apply to the alias tree rooted at the
given Symbol. The WholeTree policy will cause the move/removal to apply to all
aliases in the alias tree, including parents and siblings of the given Symbol.

Together these changes aim to satisify the following:

- Avoid substantially increasing costs for non-aliases. The new HasAliasInfo internal flag on Symbol allows us to quickly identify symbols that are neither aliases nor aliased (hopefully this will cover the majority of symbols) and skip any further alias-related work.

- Allow clients to treat aliases like ordinary symbols for most purposes. E.g. aliases will show up during symbol iteration like any ordinary symbol, keeping "find-by-name" searches simple.

- Allow clients to easily update groups of aliases (via alias_tree iteration).

- Provide detailed alias information to clients who want it (via aliases(...) and getAliasTarget(...))

- Force clients to think about aliases where they need to in order to keep them consistent. E.g. Requiring a policy choice when moving or removing symbols.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D132345

Files:
  llvm/include/llvm/ExecutionEngine/JITLink/JITLink.h
  llvm/lib/ExecutionEngine/JITLink/COFFLinkGraphBuilder.cpp
  llvm/lib/ExecutionEngine/JITLink/DefineExternalSectionStartAndEndSymbols.h
  llvm/lib/ExecutionEngine/JITLink/JITLink.cpp
  llvm/lib/ExecutionEngine/JITLink/JITLinkGeneric.cpp
  llvm/lib/ExecutionEngine/Orc/MachOPlatform.cpp
  llvm/lib/ExecutionEngine/Orc/ObjectLinkingLayer.cpp
  llvm/tools/llvm-jitlink/llvm-jitlink.cpp
  llvm/unittests/ExecutionEngine/JITLink/EHFrameSupportTests.cpp
  llvm/unittests/ExecutionEngine/JITLink/LinkGraphTests.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D132345.454376.patch
Type: text/x-patch
Size: 54243 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220822/578988d3/attachment-0001.bin>