On Thu, Mar 22, 2018 at 11:46 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2018-03-22 11:36:47 +1300, Thomas Munro wrote:
>> Not sure if we'll want to try to actively identify and avoid known
>> buggy versions or not?
>
> I'm currently not inclined to invest a lot of effort into it, besides
> trying to get the bug fixed.
>
> A possible testcase would be to call
> createLocalIndirectStubsManagerBuilder() and report an error if it
> returns nullptr. But that'd fail once the bug is fixed, because we don't
> actually *need* that functionality, it's just that LLVM instantiates the
> stub manager unconditionally for some reason.
So how about we test createLocalIndirectStubsManagerBuilder(), and if
it's nullptr then we also test the LLVM version number? For each
major release (3.9, 4.0, 5.0, ... you can see that they did the same
kind of versioning schema change that we did!) there will eventually
be a minor/patch release number where this works even when nullptr is
returned here.
This problem is going to come up on any architecture not covered in
the following code, namely anything but x86, x86_64 and (since 6.0)
aarch64 (aka arm64), so we definitely don't want to leave JIT disabled
once that bug is fixed:
https://github.com/llvm-mirror/llvm/blob/release_39/lib/ExecutionEngine/Orc/IndirectionUtils.cpp#L48
https://github.com/llvm-mirror/llvm/blob/release_60/lib/ExecutionEngine/Orc/IndirectionUtils.cpp#L48
--
Thomas Munro
http://www.enterprisedb.com
