clang-offload-bundler tool may hang under certain conditions when it extracts a subset of all available device bundles from the fat binary that is handled by the BinaryFileHandler. This patch fixes this problem.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Sure. The main unbundling loop looks as follows (see loop on line 745)
while (!Worklist.empty()) { StringRef CurTriple = FH.get()->ReadBundleStart(Input); if (CurTriple.empty()) break; auto Output = Worklist.find(CurTriple); if (Output == Worklist.end()) { continue; } ... }
Here Worklist is a collection of bundles that need to be extracted, and FH is the object implementing FileHandler interface. FileHandler::ReadBundleStart() returns the name of the bundle FH currently points to. As you can see in the loop above if the name returned by that call is not in the set of bundles that need to be extracted, we just call ReadBundleStart next time assuming that FileHandler would advance to the next bundle on each ReadBundleStart call. That assumption is correct for all FileHandler implementations except BinaryFileHandler which does not advance to the next bundle when this method is called. As a result we are going into an infinite loop if we need to skip a bundle for the file handled by the BinaryFileHandler . This patch just fixes this problem in the BinaryFileHandler implementation.
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp | ||
---|---|---|
301 ↗ | (On Diff #217232) | Just noticed that this line now looks redundant and should be removed. |
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp | ||
---|---|---|
295 ↗ | (On Diff #217485) | Maybe just: const BundleInfo &Bundle = *CurBundleInfo; std::advance(CurBundleInfo, 1); return Bundle.first(); instead of all these changes? |
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp | ||
---|---|---|
295 ↗ | (On Diff #217485) | It could be done like this if CurBundleInfo was not used in ReadBundle. |