[cling] Inject symbols from libc_nonshared.a #13286
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Starting build on |
jalopezg-git
approved these changes
Jul 19, 2023
Comment on lines
588
to
593
| SymbolMap LibcNonsharedSymbols; | ||
| LibcNonsharedSymbols[Jit->mangleAndIntern("lstat")] = JITEvaluatedSymbol( | ||
| static_cast<JITTargetAddress>(reinterpret_cast<uintptr_t>(&lstat)), | ||
| JITSymbolFlags::Exported); | ||
| cantFail( | ||
| Jit->getMainJITDylib().define(absoluteSymbols(LibcNonsharedSymbols))); |
There was a problem hiding this comment.
I wonder whether we could reuse IncrementalJIT::addOrReplaceDefinition() for this, but other than that LGTM!
vgvassilev
reviewed
Jul 19, 2023
vgvassilev
approved these changes
Jul 19, 2023
|
Build failed on mac12arm/cxx20. Failing tests: |
These symbols may not be found automatically. See also upstream issue llvm/llvm-project#61289. This fixes the test DynamicLibraryManager/cached_realpath.C, approach by Lang Hames.
|
Starting build on |
hahnjo
changed the title
|
Even better now 👍! Many thanks, @hahnjo! |
|
Does this also fix cling with devtoolset? Or could a similar approach be used? (I forgot the exact library name that provides the extra symbols.) |
No.
Not quite, for that we actually have to load the full static library and stuff it into a |
|
Build failed on ROOT-debian10-i386/soversion. Failing tests: |
LebedevRI
added a commit
to LebedevRI/Halide
that referenced
this pull request
Aug 11, 2024
The original workaround is very partial, and was not really working in my experience, even after making it non-GCC specific. Instead: 1. Ensure that the library that actually provides that symbol (as per the compiler used!) is actually linked into. This was not enough still. 2. Replace `HalideJITMemoryManager` hack with a more direct approach of actually telling the JIT the address of the symbol. 3. While there, move the symbol's forward definition to outside of namespaces. It's a global symbol, it makes sense to place it there. This makes python binding tests pass on i386, and i'm really happy about that. Refs. llvm/llvm-project#61289 Inspired by root-project/root#13286
LebedevRI
added a commit
to LebedevRI/Halide
that referenced
this pull request
Aug 11, 2024
The original workaround is very partial, and was not really working in my experience, even after making it non-GCC specific. Instead: 1. Ensure that the library that actually provides that symbol (as per the compiler used!) is actually linked into. This was not enough still. 2. Replace `HalideJITMemoryManager` hack with a more direct approach of actually telling the JIT the address of the symbol. 3. While there, move the symbol's forward definition to outside of namespaces. It's a global symbol, it makes sense to place it there. This makes python binding tests pass on i386, and i'm really happy about that. Refs. llvm/llvm-project#61289 Inspired by root-project/root#13286
LebedevRI
added a commit
to LebedevRI/Halide
that referenced
this pull request
Aug 11, 2024
The original workaround is very partial, and was not really working in my experience, even after making it non-GCC specific. Instead: 1. Ensure that the library that actually provides that symbol (as per the compiler used!) is actually linked into. This was not enough still. 2. Replace `HalideJITMemoryManager` hack with a more direct approach of actually telling the JIT the address of the symbol. 3. While there, move the symbol's forward definition to outside of namespaces. It's a global symbol, it makes sense to place it there. This makes python binding tests pass on i386, and i'm really happy about that. Refs. llvm/llvm-project#61289 Inspired by root-project/root#13286
LebedevRI
added a commit
to LebedevRI/Halide
that referenced
this pull request
Aug 11, 2024
The original workaround is very partial, and was not really working in my experience, even after making it non-GCC specific. Instead: 1. Ensure that the library that actually provides that symbol (as per the compiler used!) is actually linked into. This was not enough still. 2. Replace `HalideJITMemoryManager` hack with a more direct approach of actually telling the JIT the address of the symbol. 3. While there, move the symbol's forward definition to outside of namespaces. It's a global symbol, it makes sense to place it there. This makes python binding tests pass on i386, and i'm really happy about that. Refs. llvm/llvm-project#61289 Inspired by root-project/root#13286
LebedevRI
added a commit
to LebedevRI/Halide
that referenced
this pull request
Aug 11, 2024
The original workaround is very partial, and was not really working in my experience, even after making it non-GCC specific. Instead: 1. Ensure that the library that actually provides that symbol (as per the compiler used!) is actually linked into. This was not enough still. 2. Replace `HalideJITMemoryManager` hack with a more direct approach of actually telling the JIT the address of the symbol. 3. While there, move the symbol's forward definition to outside of namespaces. It's a global symbol, it makes sense to place it there. This makes python binding tests pass on i386, and i'm really happy about that. Refs. llvm/llvm-project#61289 Inspired by root-project/root#13286 Forwarded: halide#8389 Gbp-Pq: Name 0010-JITModule-rework-fix-__udivdi3-handling.patch
LebedevRI
added a commit
to LebedevRI/Halide
that referenced
this pull request
Aug 13, 2024
The original workaround is very partial, and was not really working in my experience, even after making it non-GCC specific. Instead: 1. Ensure that the library that actually provides that symbol (as per the compiler used!) is actually linked into. This was not enough still. 2. Replace `HalideJITMemoryManager` hack with a more direct approach of actually telling the JIT the address of the symbol. 3. While there, move the symbol's forward definition to outside of namespaces. It's a global symbol, it makes sense to place it there. This makes python binding tests pass on i386, and i'm really happy about that. Refs. llvm/llvm-project#61289 Inspired by root-project/root#13286 Forwarded: halide#8389 Gbp-Pq: Name 0010-JITModule-rework-fix-__udivdi3-handling.patch
LebedevRI
added a commit
to LebedevRI/Halide
that referenced
this pull request
Aug 13, 2024
The original workaround is very partial, and was not really working in my experience, even after making it non-GCC specific. Instead: 1. Ensure that the library that actually provides that symbol (as per the compiler used!) is actually linked into. This was not enough still. 2. Replace `HalideJITMemoryManager` hack with a more direct approach of actually telling the JIT the address of the symbol. 3. While there, move the symbol's forward definition to outside of namespaces. It's a global symbol, it makes sense to place it there. This makes python binding tests pass on i386, and i'm really happy about that. Refs. llvm/llvm-project#61289 Inspired by root-project/root#13286 Forwarded: halide#8389 Gbp-Pq: Name 0010-JITModule-rework-fix-__udivdi3-handling.patch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These symbols may not be found automatically. See also upstream issue llvm/llvm-project#61289. This fixes the test
DynamicLibraryManager/cached_realpath.C, approach by Lang Hames.