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 link c++ standard library in LLVM's JIT? #81

Closed
lanistor opened this issue Dec 26, 2019 · 0 comments
Closed

How to link c++ standard library in LLVM's JIT? #81

lanistor opened this issue Dec 26, 2019 · 0 comments

Comments

@lanistor
Copy link

I have custom functions written by c++, and they are using lots of c++ standard libraries, such as iostream, map, vector, i can add my functions to JIT using addObjectFile, but the standard libraries' functions cannot be found, how cound i link them with my JIT?

My case:
ffi.cpp

#include <iostream>

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

main.cpp, the built/ffi is created by clang++ ffi.cpp -c -o build/ffi

int main(int argc, char *argv[]) {

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

  ExitOnError ExitOnErr;

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

  auto jit =
      ExitOnErr(LLJITBuilder()
                    .setJITTargetMachineBuilder(std::move(JTMB))
                    .create());

  char ffi_file[] = "build/ffi";
  jit->addObjectFile(ExitOnErr(errorOrToExpected(MemoryBuffer::getFileAsStream(ffi_file))));

The add function can be found, but the functions of iostream cannot be found, and run with error:

JIT session error: Symbols not found: [ __Unwind_Resume, __ZNKSt3__16locale9use_facetERNS0_2idE, __ZNKSt3__18ios_base6getlocEv, __ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEmc, __ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEED1Ev, __ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE3putEc, __ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5flushEv, __ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryC1ERS3_, __ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryD1Ev, __ZNSt3__14coutE, __ZNSt3__15ctypeIcE2idE, __ZNSt3__16localeD1Ev, __ZNSt3__18ios_base33__set_badbit_and_consider_rethrowEv, __ZNSt3__18ios_base5clearEj, __ZSt9terminatev, ___cxa_begin_catch, ___cxa_end_catch, ___gxx_personality_v0, _memset, _strlen ]
Failed to materialize symbols: { (0x7fd514708170, { __ZNSt3__124__put_character_sequenceIcNS_11char_traitsIcEEEERNS_13basic_ostreamIT_T0_EES7_PKS4_m, __ZNSt3__1lsINS_11char_traitsIcEEEERNS_13basic_ostreamIcT_EES6_PKc, __ZNSt3__111char_traitsIcE11eq_int_typeEii, __ZNSt3__111char_traitsIcE3eofEv, __ZNSt3__111char_traitsIcE6lengthEPKc, _main, _link, _add, ___clang_call_terminate, __ZNSt3__116__pad_and_outputIcNS_11char_traitsIcEEEENS_19ostreambuf_iteratorIT_T0_EES6_PKS4_S8_S8_RNS_8ios_baseES4_ }) }
dvirtz added a commit to dvirtz/llvm-project that referenced this issue Aug 29, 2023
dvirtz pushed a commit to dvirtz/llvm-project that referenced this issue Aug 29, 2023
## [2.3.1](dvirtz/vscode-parquet-viewer@v2.3.0...v2.3.1) (2023-07-27)

### Bug Fixes

* move pkg-prebuilds should be a runtime dep ([58c15af](dvirtz/vscode-parquet-viewer@58c15af)), closes [llvm#81](dvirtz/vscode-parquet-viewer#81)

### General maintenance

* **deps-dev:** bump word-wrap from 1.2.3 to 1.2.4 ([3c743be](dvirtz/vscode-parquet-viewer@3c743be))

### Build and continuous integration

* build only typescript when packaging ([4acc829](dvirtz/vscode-parquet-viewer@4acc829))
* disable hooks in CI ([947f61b](dvirtz/vscode-parquet-viewer@947f61b))
* download prebuilds before install ([43c03d9](dvirtz/vscode-parquet-viewer@43c03d9))
* ignore workspaces on release ([164abbe](dvirtz/vscode-parquet-viewer@164abbe)), closes [llvm#76](dvirtz/vscode-parquet-viewer#76)
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
RevySR pushed a commit to revyos/llvm-project that referenced this issue Apr 3, 2024
* [Clang][XTHeadVector] implement 12.10 `vdivu/vdiv/vrem/vremu`

* [Clang][XTHeadVector] test 12.10 `vdivu/vdiv/vrem/vremu`
RevySR pushed a commit to revyos/llvm-project that referenced this issue Jul 27, 2024
* [Clang][XTHeadVector] implement 12.10 `vdivu/vdiv/vrem/vremu`

* [Clang][XTHeadVector] test 12.10 `vdivu/vdiv/vrem/vremu`
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

1 participant