You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@impala.apache.org by "Quanlong Huang (Jira)" <ji...@apache.org> on 2022/02/02 01:35:00 UTC
[jira] [Created] (IMPALA-11102) LLVM codegen can't resolve boost symbols after bumping boost version to 1.74
Quanlong Huang created IMPALA-11102:
---------------------------------------
Summary: LLVM codegen can't resolve boost symbols after bumping boost version to 1.74
Key: IMPALA-11102
URL: https://issues.apache.org/jira/browse/IMPALA-11102
Project: IMPALA
Issue Type: Bug
Components: Backend
Reporter: Quanlong Huang
We currently don't have any codegen functions depending on boost non-header-only libraries. This is found in a WIP patch: [https://gerrit.cloudera.org/c/17785/3] . Patch set 3 depends on boost::locale to implement UTF8 support for upper() and lower() functions. It crashs when the UTF8 implementation is codegen:
{code:java}
F0128 15:17:45.989331 13575 llvm-codegen.cc:152] 64458eac382abfb9:85324b2c00000000] LLVM hit fatal error: Program used external function '_ZN5boost6locale9converterIcE2idE' which could not be resolved!
*** Check failure stack trace: ***
@ 0x56d70ec google::LogMessage::Fail()
@ 0x56d899c google::LogMessage::SendToLog()
@ 0x56d6a4a google::LogMessage::Flush()
@ 0x56da608 google::LogMessageFatal::~LogMessageFatal()
@ 0x2ad61a5 impala::LlvmCodegenHandleError()
@ 0x55ddccd llvm::report_fatal_error()
@ 0x52fdba4 llvm::RuntimeDyldImpl::resolveExternalSymbols()
@ 0x52fdcf4 llvm::RuntimeDyldImpl::resolveRelocations()
@ 0x50c1358 llvm::MCJIT::finalizeLoadedModules()
@ 0x50c1a31 llvm::MCJIT::finalizeObject()
@ 0x2ae0b0a impala::LlvmCodeGen::FinalizeModule()
@ 0x24cd76b impala::FragmentState::CodegenHelper()
@ 0x24cceb4 impala::FragmentState::InvokeCodegen()
@ 0x24d620e impala::FragmentInstanceState::Open()
@ 0x24d2a74 impala::FragmentInstanceState::Exec()
@ 0x240f291 impala::QueryState::ExecFInstance()
@ 0x240d68f _ZZN6impala10QueryState15StartFInstancesEvENKUlvE_clEv
@ 0x241231b _ZN5boost6detail8function26void_function_obj_invoker0IZN6impala10QueryState15StartFInstancesEvEUlvE_vE6invokeERNS1_15function_bufferE
@ 0x22af13b boost::function0<>::operator()()
@ 0x2a79976 impala::Thread::SuperviseThread()
@ 0x2a822c6 boost::_bi::list5<>::operator()<>()
@ 0x2a821ea boost::_bi::bind_t<>::operator()()
@ 0x2a821ab boost::detail::thread_data<>::run()
@ 0x4380a90 thread_proxy
@ 0x7f552827e6b9 start_thread
@ 0x7f5524cb951c clone{code}
The previous boost version is 1.61 which doesn't have this issue. We might encounter the same issue if any codegened function depends on boost libraries.
One difference between boost 1.61 and 1.74 is that symbols are now compiled with hidden visibility by default:
{code:java}
$ readelf -s --wide toolchain/toolchain-packages-gcc7.5.0/boost-1.74.0-p1/lib/libboost_locale.a | grep _ZN5boost6locale9converterIcE2idE
25: 0000000000000028 8 OBJECT GLOBAL HIDDEN 4 _ZN5boost6locale9converterIcE2idE
142: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _ZN5boost6locale9converterIcE2idE
140: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _ZN5boost6locale9converterIcE2idE
$ readelf -s --wide toolchain/toolchain-packages-gcc7.5.0/boost-1.61.0-p2/lib/libboost_locale.a | grep _ZN5boost6locale9converterIcE2idE
25: 0000000000000028 8 OBJECT GLOBAL DEFAULT 4 _ZN5boost6locale9converterIcE2idE
141: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _ZN5boost6locale9converterIcE2idE
140: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND _ZN5boost6locale9converterIcE2idE{code}
In boost-1.74, the visibility is HIDDEN. In boost-1.61, it's DEFAULT (global).
Our current LLVM version is 5.0.1. We might need to investigate if it's a LLVM issue and fixed in higher versions, or compile boost with GLOBAL visibility for symbols.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)