On Fri, Feb 2, 2018 at 5:11 PM, Thomas Munro
<thomas.mu...@enterprisedb.com> wrote:
> Another small thing which might be environmental... llvmjit_types.bc
> is getting installed into ${prefix}/lib here, but you're looking for
> it in ${prefix}/lib/postgresql:
Is there something broken about my installation? I see simple
arithmetic expressions apparently compiling and working but I can
easily find stuff that breaks... so far I think it's anything
involving string literals:
postgres=# set jit_above_cost = 0;
SET
postgres=# select quote_ident('x');
ERROR: failed to resolve name MakeExpandedObjectReadOnlyInternal
Well actually just select 'hello world' does it. I've attached a backtrace.
Tab completion is broken for me with jit_above_cost = 0 due to
tab-complete.c queries failing with various other errors including:
set <tab>:
ERROR: failed to resolve name ExecEvalScalarArrayOp
update <tab>:
ERROR: failed to resolve name quote_ident
show <tab>:
ERROR: failed to resolve name slot_getsomeattrs
I wasn't sure from your status message how much of this is expected at
this stage...
This is built from:
commit 302b7a284d30fb0e00eb5f0163aa933d4d9bea10 (HEAD -> jit, andresfreund/jit)
... plus the extern "C" tweak I posted earlier to make my clang 4.0
compiler happy, built on a FreeBSD 11.1 box with:
./configure --prefix=/home/munro/install/ --enable-tap-tests
--enable-cassert --enable-debug --enable-depend --with-llvm CC="ccache
cc" CXX="ccache c++" CXXFLAGS="-std=c++11"
LLVM_CONFIG=/usr/local/llvm50/bin/llvm-config
--with-libraries="/usr/local/lib" --with-includes="/usr/local/include"
The clang that was used for bitcode was the system /usr/bin/clang,
version 4.0. Is it a problem that I used that for compiling the
bitcode, but LLVM5 for JIT? I actually tried
CLANG=/usr/local/llvm50/bin/clang but ran into weird failures I
haven't got to the bottom of at ThinLink time so I couldn't get as far
as a running system.
I installed llvm50 from a package. I did need to make a tiny tweak by
hand: in src/Makefile.global, llvm-config --system-libs had said
-l/usr/lib/libexecinfo.so which wasn't linking and looks wrong to me
so I changed it to -lexecinfo, noted that it worked and reported a bug
upstream: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225621
--
Thomas Munro
http://www.enterprisedb.com
Core file '/home/munro/junk/pgdata/postgres.core' (x86_64) was loaded.
(lldb) bt
* thread #1, name = 'postgres', stop reason = signal SIGABRT
* frame #0: 0x00000008039e284a libc.so.7`__sys_thr_kill + 10
frame #1: 0x00000008039e2814 libc.so.7`raise + 52
frame #2: 0x00000008039e2789 libc.so.7`abort + 73
frame #3: postgres`ExceptionalCondition(conditionName=<unavailable>,
errorType=<unavailable>, fileName=<unavailable>, lineNumber=<unavailable>) at
assert.c:54
frame #4: postgres`llvm_resolve_symbol(name=<unavailable>,
ctx=<unavailable>) at llvmjit.c:581
frame #5: 0x0000000000bef86f
postgres`_ZZN4llvm17OrcCBindingsStack14createResolverEPFmPKcPvES3_ENKUlRKNSt3__112basic_stringIcNS6_11char_traitsIcEENS6_9allocatorIcEEEEE_clESE_
+ 575
frame #6: 0x0000000000bef602
postgres`_ZN4llvm3orc14LambdaResolverIZNS_17OrcCBindingsStack14createResolverEPFmPKcPvES5_EUlRKNSt3__112basic_stringIcNS8_11char_traitsIcEENS8_9allocatorIcEEEEE_ZNS2_14createResolverES7_S5_EUlSG_E0_E24findSymbolInLogicalDylibESG_
+ 18
frame #7: 0x000000000187f063
postgres`llvm::RuntimeDyldImpl::resolveExternalSymbols(void) + 675
frame #8: 0x000000000187e499
postgres`llvm::RuntimeDyldImpl::resolveRelocations(void) + 201
frame #9: 0x0000000001884b7e
postgres`llvm::RuntimeDyld::finalizeWithMemoryManagerLocking(void) + 30
frame #10: 0x0000000000bf127d
postgres`_ZN4llvm3orc24RTDyldObjectLinkingLayer20ConcreteLinkedObjectINSt3__110shared_ptrINS_11RuntimeDyld13MemoryManagerEEENS4_INS_17JITSymbolResolverEEEZNS1_9addObjectENS4_INS_6object12OwningBinaryINSA_10ObjectFileEEEEES9_EUlNS3_15__list_iteratorINS3_10unique_ptrINS0_28RTDyldObjectLinkingLayerBase12LinkedObjectENS3_14default_deleteISI_EEEEPvEERS5_RKSE_NS3_8functionIFvvEEEE_E8finalizeEv
+ 221
frame #11: 0x0000000000bf19fb
postgres`_ZNSt3__128__invoke_void_return_wrapperIN4llvm8ExpectedImEEE6__callIJRZNS1_3orc24RTDyldObjectLinkingLayer20ConcreteLinkedObjectINS_10shared_ptrINS1_11RuntimeDyld13MemoryManagerEEENS9_INS1_17JITSymbolResolverEEEZNS7_9addObjectENS9_INS1_6object12OwningBinaryINSF_10ObjectFileEEEEESE_EUlNS_15__list_iteratorINS_10unique_ptrINS6_28RTDyldObjectLinkingLayerBase12LinkedObjectENS_14default_deleteISN_EEEEPvEERSA_RKSJ_NS_8functionIFvvEEEE_E21getSymbolMaterializerENS_12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEEEUlvE_EEES3_DpOT_
+ 59
frame #12: 0x0000000000bf1982
postgres`_ZNSt3__110__function6__funcIZN4llvm3orc24RTDyldObjectLinkingLayer20ConcreteLinkedObjectINS_10shared_ptrINS2_11RuntimeDyld13MemoryManagerEEENS6_INS2_17JITSymbolResolverEEEZNS4_9addObjectENS6_INS2_6object12OwningBinaryINSC_10ObjectFileEEEEESB_EUlNS_15__list_iteratorINS_10unique_ptrINS3_28RTDyldObjectLinkingLayerBase12LinkedObjectENS_14default_deleteISK_EEEEPvEERS7_RKSG_NS_8functionIFvvEEEE_E21getSymbolMaterializerENS_12basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEEEUlvE_NS11_IS14_EEFNS2_8ExpectedImEEvEEclEv
+ 18
frame #13: 0x0000000000bf1ace postgres`llvm::JITSymbol::getAddress(void) +
62
frame #14: 0x0000000000becfb5
postgres`llvm::OrcCBindingsStack::findSymbolAddress(unsigned long&,
std::__1::basic_string<char, unsigned long&::char_traits<char>, unsigned
long&::allocator<char> > const&, bool) + 101
frame #15: 0x0000000000becf22 postgres`LLVMOrcGetSymbolAddress + 178
frame #16: postgres`llvm_get_function(context=0x000000080434b260,
funcname=<unavailable>) at llvmjit.c:239
frame #17: postgres`ExecRunCompiledExpr(state=0x00000008043f6758,
econtext=0x00000008043f6448, isNull="") at execExprCompile.c:359
frame #18: postgres`ExecResult [inlined]
ExecEvalExprSwitchContext(state=0x00000008043f6758,
econtext=0x00000008043f6448, isNull=<unavailable>) at executor.h:310
frame #19: postgres`ExecResult [inlined]
ExecProject(projInfo=0x00000008043f6750) at executor.h:344
frame #20: postgres`ExecResult(pstate=<unavailable>) at nodeResult.c:136
frame #21: postgres`standard_ExecutorRun [inlined]
ExecProcNode(node=<unavailable>) at executor.h:244
frame #22: postgres`standard_ExecutorRun [inlined]
ExecutePlan(estate=<unavailable>, planstate=0x00000008043f6330,
use_parallel_mode='\0', operation=<unavailable>, sendTuples='\x01',
numberTuples=0, direction=<unavailable>, dest=<unavailable>) at execMain.c:1721
frame #23: postgres`standard_ExecutorRun(queryDesc=<unavailable>,
direction=<unavailable>, count=0, execute_once=<unavailable>) at execMain.c:364
frame #24: postgres`PortalRunSelect(portal=0x0000000804364118,
forward=<unavailable>, count=0, dest=<unavailable>) at pquery.c:932
frame #25: postgres`PortalRun(portal=0x0000000804364118,
count=<unavailable>, isTopLevel='\x01', run_once=<unavailable>,
dest=<unavailable>, altdest=<unavailable>, completionTag=<unavailable>) at
pquery.c:773
frame #26: postgres`exec_simple_query(query_string="select 'hello world';")
at postgres.c:1121
frame #27: postgres`PostgresMain(argc=<unavailable>, argv=<unavailable>,
dbname=<unavailable>, username=<unavailable>) at postgres.c:0
frame #28: postgres`PostmasterMain [inlined] BackendRun at postmaster.c:4412
frame #29: postgres`PostmasterMain [inlined] BackendStartup at
postmaster.c:4084
frame #30: postgres`PostmasterMain at postmaster.c:1757
frame #31: postgres`PostmasterMain(argc=<unavailable>,
argv=0x0000000000000002) at postmaster.c:1365
frame #32: postgres`main(argc=<unavailable>, argv=<unavailable>) at
main.c:228
frame #33: 0x000000000066baef postgres`_start + 383
(
