Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to use LLJIT::addObjectFile with extra libraries? #59

Closed
lanistor opened this issue Dec 12, 2019 · 2 comments
Closed

How to use LLJIT::addObjectFile with extra libraries? #59

lanistor opened this issue Dec 12, 2019 · 2 comments

Comments

@lanistor
Copy link

lanistor commented Dec 12, 2019

When i try to link c++ function, error occured:

JIT session error: Symbols not found: { ___cxa_begin_catch, __ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5flushEv, __Unwind_Resume, ___cxa_end_catch, __ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryD1Ev, __ZNSt3__18ios_base5clearEj, __ZNSt3__15ctypeIcE2idE, __ZNKSt3__16locale9use_facetERNS0_2idE, __ZSt9terminatev, __ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEED1Ev, __ZNSt3__14coutE, _memset, __ZNSt3__16localeD1Ev, _strlen, __ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEmc, ___gxx_personality_v0, __ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryC1ERS3_, __ZNSt3__18ios_base33__set_badbit_and_consider_rethrowEv, ___cxa_call_unexpected, __ZNKSt3__18ios_base6getlocEv, __ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE3putEc }
Failed to materialize symbols: { (0x7fdb6440b810, { __ZNSt3__1lsINS_11char_traitsIcEEEERNS_13basic_ostreamIcT_EES6_PKc, __ZNSt3__124__put_character_sequenceIcNS_11char_traitsIcEEEERNS_13basic_ostreamIT_T0_EES7_PKS4_m, _link, __ZNSt3__116__pad_and_outputIcNS_11char_traitsIcEEEENS_19ostreambuf_iteratorIT_T0_EES6_PKS4_S8_S8_RNS_8ios_baseES4_, ___clang_call_terminate, _add, __ZNSt3__111char_traitsIcE3eofEv, __ZNSt3__111char_traitsIcE11eq_int_typeEii, _main, __ZNSt3__111char_traitsIcE6lengthEPKc }) }

Here are my code:
main.cpp

InitLLVM X(argc, argv);
  InitializeNativeTarget();
  InitializeNativeTargetAsmPrinter();
  ThreadSafeContext context(std::make_unique<LLVMContext>());

  ExitOnError ExitOnErr;

  jitlink::InProcessMemoryManager MemMgr;

  auto JTMB = ExitOnErr(JITTargetMachineBuilder::detectHost());
  JTMB.setCodeModel(CodeModel::Small);

  auto jit =
      ExitOnErr(LLJITBuilder()
                    .setJITTargetMachineBuilder(std::move(JTMB))
                    .setObjectLinkingLayerCreator([&](ExecutionSession &ES, const Triple &TT) {
                      return std::make_unique<ObjectLinkingLayer>(ES, MemMgr);
                    })
                    .create());
  auto ffi = ExitOnErr(errorOrToExpected(MemoryBuffer::getFileAsStream("build/ffi.o")));
  jit->addObjectFile(std::move(ffi));

  char func_name[] = "add";
  auto add              = ExitOnErr(jit->lookup(func_name));
  int (*func)(int, int) = (int (*)(int, int))add.getAddress();
  int result            = func(111, 222);

ffi.cpp

#include <iostream>

extern "C" int add(int a, int b) {
  std::cout << "add function run" << std::endl;
  return a + b;
}
int main() {
  return add(1, 2);
}

ffi.o was build by clang++ -std=c++17 -stdlib=libc++ ffi.cpp -c -o build/ffi.o;
If using clang++ -std=c++17 -stdlib=libc++ ffi.cpp -o build/ffi.o;, another error will occour:

JIT session error: Unsupported file format

JIT session error: Failed to materialize symbols: { (0x7fc530a05580, { _add, __ZNSt3__111char_traitsIcE11eq_int_typeEii, __mh_execute_header, __ZNSt3__124__put_character_sequenceIcNS_11char_traitsIcEEEERNS_13basic_ostreamIT_T0_EES7_PKS4_m, __ZNSt3__111char_traitsIcE6lengthEPKc, _main, __ZNSt3__111char_traitsIcE3eofEv, __ZNSt3__1lsINS_11char_traitsIcEEEERNS_13basic_ostreamIcT_EES6_PKc }) }
Failed to materialize symbols: { (0x7fc530a05580, { _link }) }

Relative question: issues/57

@lhames
Copy link
Contributor

lhames commented Dec 12, 2019

JIT session error: Symbols not found: { ___cxa_begin_catch, ...
Failed to materialize symbols: { (0x7fdb6440b810, {__ZNSt3__1lsINS_11char_traitsIcEEEERNS_13basic_ostreamIcT_EES6_PKc,...

You seem to have guessed the issue, but to confirm: LLVM's JIT acts as a linker, and you are seeing missing symbols errors because you don't have definitions of some of the symbols that your relocatable object is using. You need to load definitions of those functions into the JIT, or link them into the JIT executable and then make the JIT executable's symbols visible to JIT'd code. See: https://llvm.org/docs/ORCv2.html#how-to-add-process-and-library-symbols-to-the-jitdylibs

In your case a glance at the missing symbols suggest that you will at least need to build your JIT with RTTI and exceptions turned on. I'm not sure whether you will have to do anything special to pull in the iostreams definitions.

clang++ -std=c++17 -stdlib=libc++ ffi.cpp -o build/ffi.o

As I mentioned in #57 you need to use -c -o to produce a relocatable object. Using just -o will result in an executable which definitely will not work.

@lanistor
Copy link
Author

@lhames Yeah, it works. Thank you so much.

searlmc1 referenced this issue in ROCm/llvm-project Aug 23, 2023
jeffreytan81 pushed a commit to jeffreytan81/llvm-project that referenced this issue Sep 21, 2023
… provider

We noticed some performance issue while in lldb-vscode for grabing the name of the SBValue.
Profiling shows SBValue::GetName() can cause synthetic children provider of shared/unique_ptr
to deference underlying object and complete it type.

This patch lazily moves the dereference from synthetic child provider's Update() method to
GetChildAtIndex() so that SBValue::GetName() won't trigger the slow code path.

Here is the culprit slow code path:
```
...
frame llvm#59: 0x00007ff4102e0660 liblldb.so.15`SymbolFileDWARF::CompleteType(this=<unavailable>, compiler_type=0x00007ffdd9829450) at SymbolFileDWARF.cpp:1567:25 [opt]
...
frame llvm#67: 0x00007ff40fdf9bd4 liblldb.so.15`lldb_private::ValueObject::Dereference(this=0x0000022bb5dfe980, error=0x00007ffdd9829970) at ValueObject.cpp:2672:41 [opt]
frame llvm#68: 0x00007ff41011bb0a liblldb.so.15`(anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::Update(this=0x000002298fb94380) at LibStdcpp.cpp:403:40 [opt]
frame llvm#69: 0x00007ff41011af9a liblldb.so.15`lldb_private::formatters::LibStdcppSharedPtrSyntheticFrontEndCreator(lldb_private::CXXSyntheticChildren*, std::shared_ptr<lldb_private::ValueObject>) [inlined] (anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::LibStdcppSharedPtrSyntheticFrontEnd(this=0x000002298fb94380, valobj_sp=<unavailable>) at LibStdcpp.cpp:371:5 [opt]
...
frame llvm#78: 0x00007ff40fdf6e42 liblldb.so.15`lldb_private::ValueObject::CalculateSyntheticValue(this=0x000002296c66a500) at ValueObject.cpp:1836:27 [opt]
frame llvm#79: 0x00007ff40fdf1939 liblldb.so.15`lldb_private::ValueObject::GetSyntheticValue(this=<unavailable>) at ValueObject.cpp:1867:3 [opt]
frame llvm#80: 0x00007ff40fc89008 liblldb.so.15`ValueImpl::GetSP(this=0x0000022c71b90de0, stop_locker=0x00007ffdd9829d00, lock=0x00007ffdd9829d08, error=0x00007ffdd9829d18) at SBValue.cpp:141:46 [opt]
frame llvm#81: 0x00007ff40fc7d82a liblldb.so.15`lldb::SBValue::GetSP(ValueLocker&) const [inlined] ValueLocker::GetLockedSP(this=0x00007ffdd9829d00, in_value=<unavailable>) at SBValue.cpp:208:21 [opt]
frame llvm#82: 0x00007ff40fc7d817 liblldb.so.15`lldb::SBValue::GetSP(this=0x00007ffdd9829d90, locker=0x00007ffdd9829d00) const at SBValue.cpp:1047:17 [opt]
frame llvm#83: 0x00007ff40fc7da6f liblldb.so.15`lldb::SBValue::GetName(this=0x00007ffdd9829d90) at SBValue.cpp:294:32 [opt]
...
```

Differential Revision: https://reviews.llvm.org/D159542
jeffreytan81 pushed a commit that referenced this issue Sep 21, 2023
#67069)

We noticed some performance issue while in lldb-vscode for grabing the
name of the SBValue. Profiling shows SBValue::GetName() can cause
synthetic children provider of shared/unique_ptr to deference underlying
object and complete it type.

This patch lazily moves the dereference from synthetic child provider's
Update() method to GetChildAtIndex() so that SBValue::GetName() won't
trigger the slow code path.

Here is the culprit slow code path:
```
...
frame #59: 0x00007ff4102e0660 liblldb.so.15`SymbolFileDWARF::CompleteType(this=<unavailable>, compiler_type=0x00007ffdd9829450) at SymbolFileDWARF.cpp:1567:25 [opt]
...
frame #67: 0x00007ff40fdf9bd4 liblldb.so.15`lldb_private::ValueObject::Dereference(this=0x0000022bb5dfe980, error=0x00007ffdd9829970) at ValueObject.cpp:2672:41 [opt]
frame #68: 0x00007ff41011bb0a liblldb.so.15`(anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::Update(this=0x000002298fb94380) at LibStdcpp.cpp:403:40 [opt]
frame #69: 0x00007ff41011af9a liblldb.so.15`lldb_private::formatters::LibStdcppSharedPtrSyntheticFrontEndCreator(lldb_private::CXXSyntheticChildren*, std::shared_ptr<lldb_private::ValueObject>) [inlined] (anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::LibStdcppSharedPtrSyntheticFrontEnd(this=0x000002298fb94380, valobj_sp=<unavailable>) at LibStdcpp.cpp:371:5 [opt]
...
frame #78: 0x00007ff40fdf6e42 liblldb.so.15`lldb_private::ValueObject::CalculateSyntheticValue(this=0x000002296c66a500) at ValueObject.cpp:1836:27 [opt]
frame #79: 0x00007ff40fdf1939 liblldb.so.15`lldb_private::ValueObject::GetSyntheticValue(this=<unavailable>) at ValueObject.cpp:1867:3 [opt]
frame #80: 0x00007ff40fc89008 liblldb.so.15`ValueImpl::GetSP(this=0x0000022c71b90de0, stop_locker=0x00007ffdd9829d00, lock=0x00007ffdd9829d08, error=0x00007ffdd9829d18) at SBValue.cpp:141:46 [opt]
frame #81: 0x00007ff40fc7d82a liblldb.so.15`lldb::SBValue::GetSP(ValueLocker&) const [inlined] ValueLocker::GetLockedSP(this=0x00007ffdd9829d00, in_value=<unavailable>) at SBValue.cpp:208:21 [opt]
frame #82: 0x00007ff40fc7d817 liblldb.so.15`lldb::SBValue::GetSP(this=0x00007ffdd9829d90, locker=0x00007ffdd9829d00) const at SBValue.cpp:1047:17 [opt]
frame #83: 0x00007ff40fc7da6f liblldb.so.15`lldb::SBValue::GetName(this=0x00007ffdd9829d90) at SBValue.cpp:294:32 [opt]
...
```

Differential Revision: https://reviews.llvm.org/D159542
zhanyi22333 pushed a commit to zhanyi22333/llvm-project that referenced this issue Mar 7, 2024
llvm#59)

* [Clang][XTHeadVector] Define `vwadd/vwsub`

* [Clang][XTHeadVector] Tes `vwadd/vwsub`

* [Clang][XTHeadVector] Tes `vwadd/vwsub` wrappers
RevySR pushed a commit to revyos/llvm-project that referenced this issue Apr 3, 2024
llvm#59)

* [Clang][XTHeadVector] Define `vwadd/vwsub`

* [Clang][XTHeadVector] Tes `vwadd/vwsub`

* [Clang][XTHeadVector] Tes `vwadd/vwsub` wrappers
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants