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.

Sign up for GitHub

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

Jump to bottom

Assertion failed in example HowToUseLLJIT #69

Closed
paperchalice opened this issue Dec 19, 2019 · 1 comment
Closed

Assertion failed in example HowToUseLLJIT #69

paperchalice opened this issue Dec 19, 2019 · 1 comment

Comments

@paperchalice
Copy link
Contributor

Assertion failed in HowToUseLLJIT with "Resolving symbol with incorrect flags" when call lookup
My LLVM version is 9.0.1-rc3, configured on Windows with configuration x64 and Debug.

The symbol add1 has flags Exported and callable , but the related symbol in InternalSymbols has the only flag callable.

IDE locates source to "RTDyldObjectLinkingLayer.cpp" line 143 and line 187.
@lhames
Copy link
Contributor

lhames commented Dec 20, 2019

This sounds like https://llvm.org/PR44060. The issue has been fixed on trunk, but I think it’s too late to get it into 9.0.1.

Bigcheese pushed a commit to Bigcheese/llvm-project that referenced this issue Feb 27, 2020
@cyndyishida
Merge pull request llvm#69 from shahmishal/fix-test-failure-c75cd3c7f…
eb04d90 
…0f924d5

[clang][driver][flang] Mark test as unsupported on darwin
@siggi-alpheus siggi-alpheus mentioned this issue Apr 5, 2022
Closed
@doocman doocman mentioned this issue Jun 5, 2022
Open
@dilyanpalauzov dilyanpalauzov mentioned this issue Oct 3, 2022
Open
@TatyanaDoubts TatyanaDoubts mentioned this issue Nov 4, 2022
Closed
@jharvell jharvell mentioned this issue May 7, 2023
Closed
@Bouncner Bouncner mentioned this issue Jun 12, 2023
Closed
@llvmbot llvmbot mentioned this issue Sep 15, 2023
Closed
jeffreytan81 pushed a commit to jeffreytan81/llvm-project that referenced this issue Sep 21, 2023
Lazy deference underlying object for shared/weak/unique_ptr synthetic…
64e7184 
… 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
Lazy deference underlying object for shared/weak/unique_ptr synthetic… (
9faf8b5 
#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
@paveltrpn paveltrpn mentioned this issue Feb 18, 2024
Open
zhanyi22333 pushed a commit to zhanyi22333/llvm-project that referenced this issue Mar 7, 2024
@imkiva
[Clang][XTHeadVector] Implement 12.3 vadc/vsbc/vmadc/vmsbc (llvm#69)
c061087 
* [Clang][XTHeadVector] Define `vadc/vsbc/vmadc/vmsbc`

Reference: ruyisdk#52

* [Clang][XTHeadVector] Test `vadc/vsbc/vmadc/vmsbc`
boomanaiden154 added a commit to boomanaiden154/llvm-project that referenced this issue Mar 22, 2024
@boomanaiden154
Fix clang formatting issue (llvm#69)
eb3f213 
This patch fixes a clang-formatting issue introduced in a previous patch.
RevySR pushed a commit to revyos/llvm-project that referenced this issue Apr 3, 2024
@imkiva @RevySR
[Clang][XTHeadVector] Implement 12.3 vadc/vsbc/vmadc/vmsbc (llvm#69)
0d9aaef 
* [Clang][XTHeadVector] Define `vadc/vsbc/vmadc/vmsbc`

Reference: ruyisdk#52

* [Clang][XTHeadVector] Test `vadc/vsbc/vmadc/vmsbc`
JonChesterfield pushed a commit to JonChesterfield/llvm-project that referenced this issue May 25, 2024
@randyh62
Merge pull request llvm#69 from ROCm/hipcc_docs
e51d33a 
Hipcc docs
@nilres nilres mentioned this issue May 28, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@lhames @paperchalice