- User Since
- Mar 8 2017, 5:43 PM (283 w, 6 d)
Jul 6 2022
This caused llvm builds to fail for me (using clang-14, debug, debian unstable, lld as linker):
Jun 1 2022
So far the tests in pointer-subtraction.c are mirrored in pointer-subtraction.cpp - worth continuing to do?
Nov 10 2020
It's not really the fault of this change, but the gdb support isn't really restricted to mcjit. registerJITEventListener() works with RTDyld based Orc too.
Nov 28 2018
Nov 1 2018
Darnit. Sorry for that. Good catch. Can you commit, or should I?
Oct 30 2018
This looks like a sensible improvement. There's probably not many implementors of the interface, so the renaming shouldn't cause much pain.
Jul 25 2018
Jul 24 2018
Previous approach was a brick shy of a load, which I realized after
sleeping on it. We'd just end up with undefined symbol errors for the
listeners that *are* built in (because the part of the class
implementation ptentially is in a different lib). Hence just define
Jul 23 2018
Jul 22 2018
@vchuravy Yea, that was an unnecessary, and as you notice wrong, dependency. I confirmed that just removing it is sufficient. Does that resolve your blocker?
Fix build without perf enabled, fix rebasing issues.
May 24 2018
Address reames' comments and rebase onto newer code. As
https://reviews.llvm.org/D44890 has landed, add the corresponding
C-API function as well.
This patch doesn't affect any of my use-cases, but it's possible that some clients are relying on the fact that memory will still be writable at this point.
Rebase after temporary revert of r333147.
May 23 2018
FWIW, I don't think this is really obvious / trivial enough to land w/o review by someone familiar w/ Orc and the users.
Apr 23 2018
Ping? @lhames unfortunately you're probably the only one to review this?
Ping? Any suggestions for other reviewers?
Ping? This is a simple enough addition that seems to have been envisioned when designing the Orc C stack (given that the underlying stack isn't used anywhere else, and has findSymbolIn()).
Apr 22 2018
Apr 11 2018
Ideally we would have a test for this code but given that it involves host CPU and features this seems quite tricky and not worth the benefit.
Ping? I'm using this functionality in postgres's new JIT support. It'd be cool if it were merged so we can make sure the released version of Postgres is going to use the right API, even if LLVM has to be patched for it to be available in older releases.
Ping? This is a trivial change and makes it much easier to use Orc via the C API, as otherwise suboptimal code is generated. If anybody has suggestions for further reviewers I'd also be happy.