[PATCH] D74262: [clang-offload-bundler] Enable handling of partially-linked fat objects

[George Rokos via Phabricator via cfe-commits]

grokos marked 2 inline comments as done.
grokos added a comment.

In D74262#1867245 <https://reviews.llvm.org/D74262#1867245>, @ABataev wrote:

> Partial linking may lead to some incorrect results with global constructors. How are you going to handle this?


Can you give me an example of what can break? I remember reading a conversation about some linker patch some time ago but I cannot recall the details.



================
Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:84
                        "  o   - object\n"
+                       "  oo  - object; output file is a list of unbundled objects\n"
                        "  gch - precompiled-header\n"
----------------
jdoerfert wrote:
> ABataev wrote:
> > Hmm, are you going to introduce a new kind of output? It really requires RFC.
> This is the offload-bundler tool, right? Who is using that except OpenMP (and SYCL)?
> 
> Is there a reason for `oo`? `uo` (=unboundled object), or `do` (=device object)?
No one else (at least for now). But I can send out an RFC regarding the new output anyway.

`oo` is related to the fact that under this scheme we can have multiple `.o` files as output (many `o`'s). But if you think some of the other abbreviations makes more sense, I'm happy to change it.


================
Comment at: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp:160
+  }
+
   /// Write the header of the bundled file to \a OS based on the information
----------------
jdoerfert wrote:
> I don't understand the comment. If \p FileName is a list of outputs, how does this work?
The scheme is described in the attached pdf. In short, when the host liner fetches dependencies from a static library, alongside the host bundle it also fetches the device bundle. Now, if we have multiple dependencies from multiple objects inside a static library (or multiple static libraries) the host linker will perform a partial linking between all fetched bundles for the targets we are interested in. The result is a fat object in which each target bundle is the result of concatenating the individual bundles for that target we fetched from each static library. We also keep track of the size of each fetched bundle (we use a new sizes section per target inside the fat object for this purpose) so that the unbundler can separate the partially-linked bundle into the original object files it was assembled from. Usually, we don't know a priori how many dependencies will be brought in, so we don't know how many objects we're going to have at outputs. Therefore, in `oo` unbundling mode, the user specifies a single output file per target (just like in any other unbundling mode) which the unbundler populates with the paths to the actual output device objects. Then the driver reads those paths and passes them on to the device linker.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74262/new/

https://reviews.llvm.org/D74262