[Openmp-dev] : undefined symbol: ompt_start_tool

Kelvin Li via Openmp-dev openmp-dev at lists.llvm.org
Thu Oct 29 09:11:29 PDT 2020


Hi Joachim,

> Does your libomp contain an implementation of ompt_start_tool?

It seems to be there.

$ readelf --syms /home/kli/clang-install/lib/libomp.so | grep 
ompt_start_tool
   323: 000000000011bb40   188 FUNC    WEAK   DEFAULT   11 
ompt_start_tool@@VERSION        [<localentry>: 8] 
   166: 000000000015f1b0     8 OBJECT  LOCAL  DEFAULT   25 
_ZL22ompt_start_tool_resu
  3457: 000000000011bb40   188 FUNC    WEAK   DEFAULT   11 ompt_start_tool 
        [<localentry>: 8] 


Kelvin




From:   Joachim Protze <protze.joachim at gmail.com>
To:     Kelvin Li <kli at ca.ibm.com>
Cc:     Jim Cownie <jcownie at gmail.com>, openmp-dev at lists.llvm.org
Date:   2020/10/28 01:26 PM
Subject:        [EXTERNAL] Re: [Openmp-dev] : undefined symbol: 
ompt_start_tool



Hi Kelvin,

Am 28.10.20 um 17:16 schrieb Kelvin Li:
> I tried both commands with LD_DEBUG.  It seems that somehow the 
> libarcher.so cannot be found to resolve ompt_start_tool.
> 

libomp calls ompt_start_tool directly (by name) in

https://github.com/llvm/llvm-project/blob/master/openmp/runtime/src/ompt-general.cpp#L237 


In a typical execution, this will find the implementation in libomp:

https://github.com/llvm/llvm-project/blob/master/openmp/runtime/src/ompt-general.cpp#L136 


If I did not miss something, implementation and call should be in the
same ifdef branch, i.e., both active or not.

Reasoning: This explicit call by name is necessary to catch the case of
a static tool compiled in the application (linker will prefer
ompt_start_tool from the static tool). Such static version might not be
found by dlsym.


Later, libomp implicitly assumes "libarcher to be the last entry in
OMPT_TOOL_LIBRARIES", dlopens libarcher and dlsyms ompt_start_tool:
https://github.com/llvm/llvm-project/blob/master/openmp/runtime/src/ompt-general.cpp#L275 


Therefore you see libarcher in the LD_DEBUG output.

This is how it looks for me:
$ LD_DEBUG=bindings ./a.out 2>&1| grep ompt_start_tool
      1568:              binding file libomp.so [0] to libomp.so [0]: 
normal symbol
`ompt_start_tool' [VERSION]
      1568:              binding file libarcher.so [0] to libarcher.so 
[0]: normal
symbol `ompt_start_tool'


> $ LD_DEBUG=bindings LD_LIBRARY_PATH=/home/kli/clang-install/lib ./a.out 
> 2>&1| grep ompt_start_tool
>       9105:     binding file /home/kli/clang-install/lib/libomp.so [0] 
to 
> /home/kli/clang-install/lib/libomp.so [0]: normal symbol 
`ompt_start_tool' 
> [VERSION]
>       9105:     /home/kli/clang-install/lib/libomp.so: error: symbol 
> lookup error: undefined symbol: ompt_start_tool (fatal)

Here the execution complains about the missing symbol, but does not
abort. It is unclear to me, why the execution does not abort in this case.

>       9105:     binding file /home/kli/clang-install/lib/libarcher.so 
[0] 
> to /home/kli/clang-install/lib/libarcher.so [0]: normal symbol 
> `ompt_start_tool'
> 
> $ LD_DEBUG=bindings LD_LIBRARY_PATH=/home/kli/clang-install/lib mpirun 
-np 
> 1 ./a.out 2>&1| grep ompt_start_tool
>      27652:     binding file /home/kli/clang-install/lib/libomp.so [0] 
to 
> /home/kli/clang-install/lib/libomp.so [0]: normal symbol 
`ompt_start_tool' 
> [VERSION]
>      27652:     /home/kli/clang-install/lib/libomp.so: error: symbol 
> lookup error: undefined symbol: ompt_start_tool (fatal)

Same message as above, but now the execution aborts:

> ./a.out: symbol lookup error: /home/kli/clang-install/lib/libomp.so: 
> undefined symbol: ompt_start_tool

Since the dlopen for libarcher is after the explicit call to
ompt_start_tool, it is clear that the message about libarcher is missing
here.


Does your libomp contain an implementation of ompt_start_tool?

nm /home/kli/clang-install/lib/libomp.so | grep ompt_start_tool
or
readelf --syms /home/kli/clang-install/lib/libomp.so | grep 
ompt_start_tool

- Joachim





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20201029/db46992f/attachment.html>


More information about the Openmp-dev mailing list