Summary

Trying to build WT 11.0 with -DENABLE_LLVM=ON results in a build failure:

/home/bero/temp/abf/wiredtiger/BUILD/wiredtiger-11.0.0/tools/xray_to_optrack/xra
y_to_optrack.cxx:99:27: error: no matching member function for call to 'symboliz
eCode'

    auto res = symbolizer.symbolizeCode(instr_map, iter->second);

               ~~~~~~~~~~~^~~~~~~~~~~~~

/usr/include/llvm/DebugInfo/Symbolize/Symbolize.h:63:24: note: candidate functio
n not viable: no known conversion from 'const unsigned long' to 'object::Section
edAddress' for 2nd argument

  Expected<DILineInfo> symbolizeCode(const std::string &ModuleName,

                       ^

/usr/include/llvm/DebugInfo/Symbolize/Symbolize.h:61:24: note: candidate functio
n not viable: no known conversion from 'const std::string' (aka 'const basic_str
ing<char>') to 'const llvm::object::ObjectFile' for 1st argument

  Expected<DILineInfo> symbolizeCode(const ObjectFile &Obj,

                       ^

1 error generated. 

The problem is WT is using an older LLVM API and hasn't been updated to work with current versions of LLVM.

Motivation

• Does this affect any team outside of WT?
  Not currently blocking anything because WT built without -DENABLE_LLVM=ON works and is sufficient for current use case

• How likely is it that this use case or problem will occur?
  100% if someone enables LLVM support without using an ancient version of LLVM

• If the problem does occur, what are the consequences and how severe are they?
  Build failure

• Is this issue urgent?
  No

Acceptance Criteria (Definition of Done)

WT configured with -DENABLE_LLVM=ON compiles and works when using a current version of LLVM (preferably LLVM git master as well, 15 will be released soon)

• (What all testing needs to be done as part of this ticket? Unit? Functional? Performance?Testing at MongoDB side?)
  Compile with -DENABLE_LLVM=ON and run the normal test suite on components affected by LLVM

• Documentation update
  (Does this ticket require a change in the architecture guide? If yes, please create a corresponding doc ticket.)
  No documentation changes required.

[Optional] Suggested Solution
not yet