<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/llvm/lib/ExecutionEngine/Orc/COFFPlatform.cpp, branch users/ojhunt/ptrauth-additions</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[ORC][Runtime] Add dlupdate for coff (#115448)</title>
<updated>2025-10-08T11:45:44+00:00</updated>
<author>
<name>SahilPatidar</name>
<email>patidarsahil2001@gmail.com</email>
</author>
<published>2025-10-08T11:45:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=bb36630ecd94c1b7b9f8e3aba31ed2215d43c5b2'/>
<id>bb36630ecd94c1b7b9f8e3aba31ed2215d43c5b2</id>
<content type='text'>
With the help of @lhames, This pull request introduces the dlupdate
function in the ORC runtime. dlupdate enables incremental execution of
new initializers introduced in the REPL environment. Unlike traditional
dlopen, which manages initializers, code mapping, and library reference
counts, dlupdate focuses exclusively on running new initializers.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With the help of @lhames, This pull request introduces the dlupdate
function in the ORC runtime. dlupdate enables incremental execution of
new initializers introduced in the REPL environment. Unlike traditional
dlopen, which manages initializers, code mapping, and library reference
counts, dlupdate focuses exclusively on running new initializers.</pre>
</div>
</content>
</entry>
<entry>
<title>[ORC] Refactor visit-members  in StaticLibraryDefinitionGenerator. (#141546)</title>
<updated>2025-05-27T10:58:53+00:00</updated>
<author>
<name>Lang Hames</name>
<email>lhames@gmail.com</email>
</author>
<published>2025-05-27T10:58:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6fa8657a622173c177d863b763550de4d388f73c'/>
<id>6fa8657a622173c177d863b763550de4d388f73c</id>
<content type='text'>
This refactor was motivated by two bugs identified in out-of-tree
builds:

1. Some implementations of the VisitMembersFunction type (often used to	
implement special loading semantics, e.g. -all_load or -ObjC) were assuming
that buffers for archive members were null-terminated, which they are not in
general. This was triggering occasional assertions.

2. Archives may include multiple members with the same file name, e.g.
when constructed by appending files with the same name:
  % llvm-ar crs libfoo.a foo.o
  % llvm-ar q libfoo.a foo.o
  % llvm-ar t libfoo.a foo.o
  foo.o

   While confusing, these members may be safe to link (provided that they're
   individually valid and don't define duplicate symbols). In ORC however, the
   archive member name may be used to construct an ORC initializer symbol,
   which must also be unique. In that case the duplicate member names lead to a
   duplicate definition error even if the members define unrelated symbols.

In addition to these bugs, StaticLibraryDefinitionGenerator had grown a
collection of all member buffers (ObjectFilesMap), a BumpPtrAllocator
that was redundantly storing synthesized archive member names (these are
copied into the MemoryBuffers created for each Object, but were never
freed in the allocator), and a set of COFF-specific import files.

To fix the bugs above and simplify StaticLibraryDefinitionGenerator this
patch makes the following changes:

1. StaticLibraryDefinitionGenerator::VisitMembersFunction is generalized
   to take a reference to the containing archive, and the index of the
   member within the archive. It now returns an Expected&lt;bool&gt; indicating
   whether the member visited should be treated as loadable, not loadable,
   or as invalidating the entire archive.
2. A static StaticLibraryDefinitionGenerator::createMemberBuffer method
   is added which creates MemoryBuffers with unique names of the form
   `&lt;archive-name&gt;[&lt;index&gt;](&lt;member-name&gt;)`. This defers construction of
   member names until they're loaded, allowing the BumpPtrAllocator (with
   its redundant name storage) to be removed.
3. The ObjectFilesMap (symbol name -&gt; memory-buffer-ref) is replaced
   with a SymbolToMemberIndexMap (symbol name -&gt; index) which should be
   smaller and faster to construct.
4. The 'loadability' result from VisitMemberFunctions is now taken into
   consideration when building the SymbolToMemberIndexMap so that members
   that have already been loaded / filtered out can be skipped, and do not
   take up any ongoing space.
5. The COFF ImportedDynamicLibraries member is moved out into the
   COFFImportFileScanner utility, which can be used as a
   VisitMemberFunction.

This fixes the bugs described above; and should lower memory consumption
slightly, especially for archives with many files and / or symbol where
most files are eventually loaded.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This refactor was motivated by two bugs identified in out-of-tree
builds:

1. Some implementations of the VisitMembersFunction type (often used to	
implement special loading semantics, e.g. -all_load or -ObjC) were assuming
that buffers for archive members were null-terminated, which they are not in
general. This was triggering occasional assertions.

2. Archives may include multiple members with the same file name, e.g.
when constructed by appending files with the same name:
  % llvm-ar crs libfoo.a foo.o
  % llvm-ar q libfoo.a foo.o
  % llvm-ar t libfoo.a foo.o
  foo.o

   While confusing, these members may be safe to link (provided that they're
   individually valid and don't define duplicate symbols). In ORC however, the
   archive member name may be used to construct an ORC initializer symbol,
   which must also be unique. In that case the duplicate member names lead to a
   duplicate definition error even if the members define unrelated symbols.

In addition to these bugs, StaticLibraryDefinitionGenerator had grown a
collection of all member buffers (ObjectFilesMap), a BumpPtrAllocator
that was redundantly storing synthesized archive member names (these are
copied into the MemoryBuffers created for each Object, but were never
freed in the allocator), and a set of COFF-specific import files.

To fix the bugs above and simplify StaticLibraryDefinitionGenerator this
patch makes the following changes:

1. StaticLibraryDefinitionGenerator::VisitMembersFunction is generalized
   to take a reference to the containing archive, and the index of the
   member within the archive. It now returns an Expected&lt;bool&gt; indicating
   whether the member visited should be treated as loadable, not loadable,
   or as invalidating the entire archive.
2. A static StaticLibraryDefinitionGenerator::createMemberBuffer method
   is added which creates MemoryBuffers with unique names of the form
   `&lt;archive-name&gt;[&lt;index&gt;](&lt;member-name&gt;)`. This defers construction of
   member names until they're loaded, allowing the BumpPtrAllocator (with
   its redundant name storage) to be removed.
3. The ObjectFilesMap (symbol name -&gt; memory-buffer-ref) is replaced
   with a SymbolToMemberIndexMap (symbol name -&gt; index) which should be
   smaller and faster to construct.
4. The 'loadability' result from VisitMemberFunctions is now taken into
   consideration when building the SymbolToMemberIndexMap so that members
   that have already been loaded / filtered out can be skipped, and do not
   take up any ongoing space.
5. The COFF ImportedDynamicLibraries member is moved out into the
   COFFImportFileScanner utility, which can be used as a
   VisitMemberFunction.

This fixes the bugs described above; and should lower memory consumption
slightly, especially for archives with many files and / or symbol where
most files are eventually loaded.</pre>
</div>
</content>
</entry>
<entry>
<title>[ORC] Remove COFFPlatform::DylibsToPreload. NFC.</title>
<updated>2025-05-27T03:46:12+00:00</updated>
<author>
<name>Lang Hames</name>
<email>lhames@gmail.com</email>
</author>
<published>2025-05-27T03:44:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9e66d54ed4bbbaad0175aa0758a18b31e16334a3'/>
<id>9e66d54ed4bbbaad0175aa0758a18b31e16334a3</id>
<content type='text'>
DylibsToPreload is only used in the constructor. This patch makes it a local
variable.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
DylibsToPreload is only used in the constructor. This patch makes it a local
variable.
</pre>
</div>
</content>
</entry>
<entry>
<title>[ExecutionEngine] Avoid repeated hash lookups (NFC) (#128827)</title>
<updated>2025-02-26T08:56:26+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2025-02-26T08:56:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=67d92cf3841660e9ba58a02223b7801e74db1051'/>
<id>67d92cf3841660e9ba58a02223b7801e74db1051</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[JITLink] Use target triple for LinkGraph pointer size and endianness.</title>
<updated>2025-01-14T07:11:19+00:00</updated>
<author>
<name>Lang Hames</name>
<email>lhames@gmail.com</email>
</author>
<published>2025-01-14T06:28:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=4eaff6c58ae2f130ac8d63cf2c87bbb483114876'/>
<id>4eaff6c58ae2f130ac8d63cf2c87bbb483114876</id>
<content type='text'>
Removes LinkGraph's PointerSize and Endianness members and uses the triple to
find these values instead.

Also removes some redundant Triple copies.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Removes LinkGraph's PointerSize and Endianness members and uses the triple to
find these values instead.

Also removes some redundant Triple copies.
</pre>
</div>
</content>
</entry>
<entry>
<title>[JITLink] Switch to SymbolStringPtr for Symbol names (#115796)</title>
<updated>2024-12-05T23:22:09+00:00</updated>
<author>
<name>Jared Wyles</name>
<email>jared.wyles@gmail.com</email>
</author>
<published>2024-12-05T23:22:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2ccf7ed277df28651b94bbee9fccefdf22fb074f'/>
<id>2ccf7ed277df28651b94bbee9fccefdf22fb074f</id>
<content type='text'>
Use SymbolStringPtr for Symbol names in LinkGraph. This reduces string interning
on the boundary between JITLink and ORC, and allows pointer comparisons (rather
than string comparisons) between Symbol names. This should improve the
performance and readability of code that bridges between JITLink and ORC (e.g.
ObjectLinkingLayer and ObjectLinkingLayer::Plugins).

To enable use of SymbolStringPtr a std::shared_ptr&lt;SymbolStringPool&gt; is added to
LinkGraph and threaded through to its construction sites in LLVM and Bolt. All
LinkGraphs that are to have symbol names compared by pointer equality must point
to the same SymbolStringPool instance, which in ORC sessions should be the pool
attached to the ExecutionSession.
---------

Co-authored-by: Lang Hames &lt;lhames@gmail.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use SymbolStringPtr for Symbol names in LinkGraph. This reduces string interning
on the boundary between JITLink and ORC, and allows pointer comparisons (rather
than string comparisons) between Symbol names. This should improve the
performance and readability of code that bridges between JITLink and ORC (e.g.
ObjectLinkingLayer and ObjectLinkingLayer::Plugins).

To enable use of SymbolStringPtr a std::shared_ptr&lt;SymbolStringPool&gt; is added to
LinkGraph and threaded through to its construction sites in LLVM and Bolt. All
LinkGraphs that are to have symbol names compared by pointer equality must point
to the same SymbolStringPool instance, which in ORC sessions should be the pool
attached to the ExecutionSession.
---------

Co-authored-by: Lang Hames &lt;lhames@gmail.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>Re-apply "[ORC][JITLink] Add jitlink::Scope::SideEffectsOnly" with fixes.</title>
<updated>2024-12-03T08:00:29+00:00</updated>
<author>
<name>Lang Hames</name>
<email>lhames@gmail.com</email>
</author>
<published>2024-12-03T07:12:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d09707070c7460d0887eae8f7022e816510d5eb1'/>
<id>d09707070c7460d0887eae8f7022e816510d5eb1</id>
<content type='text'>
This reapplies aba6bb0820b, which was reverted in 28e2a891210 due to bot
failures. It contains fixes to silence warnings for uncovered switches,
and for incorrect initializer-symbol handling on ELF and COFF.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reapplies aba6bb0820b, which was reverted in 28e2a891210 due to bot
failures. It contains fixes to silence warnings for uncovered switches,
and for incorrect initializer-symbol handling on ELF and COFF.
</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[ORC][JITLink] Add jitlink::Scope::SideEffectsOnly, use it in ORC Platforms."</title>
<updated>2024-12-03T05:56:23+00:00</updated>
<author>
<name>Lang Hames</name>
<email>lhames@gmail.com</email>
</author>
<published>2024-12-03T05:56:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=28e2a8912102ac442166a593f2efb15c5bd30346'/>
<id>28e2a8912102ac442166a593f2efb15c5bd30346</id>
<content type='text'>
This reverts commit aba6bb0820b247d4caf4b5e00810909214a58053 while I investigate bot
failures (e.g. https://lab.llvm.org/buildbot/#/builders/143/builds/3848)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit aba6bb0820b247d4caf4b5e00810909214a58053 while I investigate bot
failures (e.g. https://lab.llvm.org/buildbot/#/builders/143/builds/3848)
</pre>
</div>
</content>
</entry>
<entry>
<title>[ORC][JITLink] Add jitlink::Scope::SideEffectsOnly, use it in ORC Platforms.</title>
<updated>2024-12-03T04:36:03+00:00</updated>
<author>
<name>Lang Hames</name>
<email>lhames@gmail.com</email>
</author>
<published>2024-12-03T04:30:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=aba6bb0820b247d4caf4b5e00810909214a58053'/>
<id>aba6bb0820b247d4caf4b5e00810909214a58053</id>
<content type='text'>
SideEffectsOnly is a new jitlink::Scope value that corresponds to the
JITSymbolFlags::MaterializationSideEffectsOnly flag: Symbols with this scope
can be looked up (and form part of the initial interface of a LinkGraph) but
never actually resolve to an address (so can only be looked up with a
WeaklyReferencedSymbol lookup).

Previously ObjectLinkingLayer implicitly treated JITLink symbols as having this
scope, regardless of a Symbol's actual scope, if the
MaterializationSideEffectsOnly flag was set on the corresponding symbol in the
MaterializationResponsibility object. Using an explicit scope in JITLink for
this (1) allows JITLink plugins to identify and correctly handle
side-effects-only symbols, and (2) allows raw LinkGraphs to define
side-effects-only symbols without clients having to manually modify their
`MaterializationUnit::Interface`.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
SideEffectsOnly is a new jitlink::Scope value that corresponds to the
JITSymbolFlags::MaterializationSideEffectsOnly flag: Symbols with this scope
can be looked up (and form part of the initial interface of a LinkGraph) but
never actually resolve to an address (so can only be looked up with a
WeaklyReferencedSymbol lookup).

Previously ObjectLinkingLayer implicitly treated JITLink symbols as having this
scope, regardless of a Symbol's actual scope, if the
MaterializationSideEffectsOnly flag was set on the corresponding symbol in the
MaterializationResponsibility object. Using an explicit scope in JITLink for
this (1) allows JITLink plugins to identify and correctly handle
side-effects-only symbols, and (2) allows raw LinkGraphs to define
side-effects-only symbols without clients having to manually modify their
`MaterializationUnit::Interface`.
</pre>
</div>
</content>
</entry>
<entry>
<title>[Support][Error] Add ErrorAsOutParameter constructor that takes an Error by ref.</title>
<updated>2024-11-29T04:57:53+00:00</updated>
<author>
<name>Lang Hames</name>
<email>lhames@gmail.com</email>
</author>
<published>2024-11-29T04:14:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d02c1676d75a6bab1252b48da9a955fc7dc1251f'/>
<id>d02c1676d75a6bab1252b48da9a955fc7dc1251f</id>
<content type='text'>
ErrorAsOutParameter's Error* constructor supports cases where an Error might not
be passed in (because in the calling context it's known that this call won't
fail). Most clients always have an Error present however, and for them an Error&amp;
overload is more convenient.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ErrorAsOutParameter's Error* constructor supports cases where an Error might not
be passed in (because in the calling context it's known that this call won't
fail). Most clients always have an Error present however, and for them an Error&amp;
overload is more convenient.
</pre>
</div>
</content>
</entry>
</feed>
