[ORC] Add Executor Resolver Utility

[SahilPatidar]

This patch adds the new executor-side resolver API as suggested by @lhames. It introduces a DylibSymbolResolver that helps resolve symbols for each loaded dylib.

Previously, we returned a DylibHandle to the controller. Now, we wrap the native handle inside DylibSymbolResolver and return a ResolverHandle instead. This makes the code cleaner and separates the symbol resolution logic from raw handle management.

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[vgvassilev]

@lhames, this looks reasonable to me. I'd like move forward with these changes. Can you take a look?

[lhames]

Is Lookup still used after this patch? I'm not opposed to replacing raw dylib handles with Resolver objects (as long as it doesn't change the dylib lifetimes, which I don't think it does), but if we are doing that then we can drop Lookup entirely and clean up the lookup wrappers and implementations in the target process library.

[SahilPatidar]

Previously, we were returning an error for a required symbol in SelfExecutorProcessControl::lookup. Now, instead of returning an error, we return an optional and added an assertion in EPCDebugObjectRegistrar.cpp — I believe that’s why the assertion was triggered.

As you can see below, the error is being silently consumed:

  JITBuilder->setPrePlatformSetup([](llvm::orc::LLJIT &J) {
    // Try to enable debugging of JIT'd code (only works with JITLink for
    // ELF and MachO).
    consumeError(llvm::orc::enableDebuggerSupport(J));
    return llvm::Error::success();
  });

The comment here shows that debugger support is only implemented for ELF and Mach-O. That explains why the assertion fails on Windows: no valid address is returned in this case.

Instead of asserting, we could return an error when the optional has no valid address or put a check here.
For now, I tried returning an error on lookup failure.

[lhames]

Typo aside, LGTM. Thanks very much for working on this @SahilPatidar!

[lhames]

Typo in comment.

[llvm-ci]

LLVM Buildbot has detected a new failure on builder ppc64le-lld-multistage-test running on ppc64le-lld-multistage-test while building llvm at step 12 "build-stage2-unified-tree".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/168/builds/16530

Here is the relevant piece of the build log for the reference

Step 12 (build-stage2-unified-tree) failure: build (failure) (timed out)
...
255.780 [6270/10/446] Linking CXX executable unittests/DebugInfo/CodeView/DebugInfoCodeViewTests
255.836 [6270/9/447] Linking CXX executable unittests/DebugInfo/MSF/DebugInfoMSFTests
255.859 [6270/8/448] Linking CXX executable unittests/Testing/ADT/TestingADTTests
255.910 [6270/7/449] Linking CXX executable unittests/FileCheck/FileCheckTests
255.940 [6270/6/450] Linking CXX executable unittests/Support/LSP/LLVMSupportLSPTests
255.940 [6270/5/451] Linking CXX executable unittests/Testing/Annotations/TestingAnnotationTests
256.014 [6270/4/452] Linking CXX executable unittests/Testing/Support/TestingSupportTests
256.175 [6270/3/453] Linking CXX executable unittests/Support/DynamicLibrary/DynamicLibraryTests
352.708 [6270/2/454] Building CXX object tools/clang/utils/TableGen/CMakeFiles/clang-tblgen.dir/ClangAttrEmitter.cpp.o
353.637 [6269/2/455] Linking CXX executable bin/clang-tblgen
command timed out: 1200 seconds without output running [b'ninja'], attempting to kill
process killed by signal 9
program finished with exit code -1
elapsedTime=1554.759593