Why is function not present in target?

Hi,

This has been the source of much frustration, but I can’t quite figure out why my toString() member function is not present in the target, according to lldb. The other functions in the compile unit are used and present, so the linker couldn’t have eliminated the compile unit. Nor could the function have been inlined, because it is not used anywhere (it’s written solely for the purpose of being used within lldb), so there’s nowhere to inline into.

So where is my function? And why isn’t lldb picking it up?

Thanks.

Ram

Hi,

a have couple of question to better understand the situation:
- what is the system you are trying this out on (OS, arch, ...)?
- are you using any funny compiler options that you think we should
know about ? (e.g. if you're using -ffunction-sections
-Wl,--gc-sections, then the function could have been removed even if
the parts of the compile unit stay)
- how exactly is your function declared? (e.g. if it's declared as
inline, or a template and unused then the compiler might not bother
emitting it)
- could you verify (e.g. by running "objdump -t") that your function
is indeed present in the resulting binary?

cheers,
pavel

Hi,

a have couple of question to better understand the situation:
- what is the system you are trying this out on (OS, arch, ...)?

macOS, x86_64.

- are you using any funny compiler options that you think we should
know about ? (e.g. if you're using -ffunction-sections
-Wl,--gc-sections, then the function could have been removed even if
the parts of the compile unit stay)

Linker invocation:

Linking Shared Object ../../bin/maci64/libmwcgir_polly.dylib
xcrun -sdk macosx10.11 clang++ -arch x86_64 -dynamiclib -single_module
-install_name @rpath/libmwcgir_polly.dylib -Wl,-mark_dead_strippable_dylib
  -arch x86_64 -mmacosx-version-min=10.9 -stdlib=libc++ -Wl,-dead_strip
-Wl,-dead_strip_dylibs -stdlib=libc++ -o
../../bin/maci64/libmwcgir_polly.dylib
../../derived/maci64/obj/src/cgir_polly/Analysis/MemoryAccess.o
../../derived/maci64/obj/src/cgir_polly/Analysis/SCOP.o
../../derived/maci64/obj/src/cgir_polly/Analysis/SCOPExtraction.o
../../derived/maci64/obj/src/cgir_polly/Analysis/SCOPStmt.o
../../derived/maci64/obj/src/cgir_polly/CodeGen/IRGeneration.o
../../derived/maci64/obj/src/cgir_polly/IslWrap/Isl.o
../../derived/maci64/obj/src/cgir_polly/Transform/Polly.o
../../derived/maci64/obj/src/cgir_polly/Transform/PollyImpl.o
../../derived/maci64/obj/src/cgir_polly/Util/PollyPrinter.o
../../derived/maci64/obj/src/cgir_polly/modver.o -L../../bin/maci64
-L../../bin/maci64 -lmwfoundation_usm -lmwcg_ir -lmwcgir_support
-lmwcgir_cgel -lut -lmwfl -L../../bin/maci64 -lboost_system
-L../../bin/maci64 -lmwcpp11compat
-L//mathworks/hub/3rdparty/R2017b/2334121/maci64/isl/lib -lisl
-L//mathworks/hub/3rdparty/R2017b/2309377/maci64/jsoncpp/lib -ljsoncpp
-L//mathworks/hub/3rdparty/R2017a/2105192/maci64/python2/lib -lpython2.7
-Wl,-rpath,@loader_path -Wl,-rpath,@loader_path/.
-Wl,-rpath,@loader_path/../../sys/os/maci64
xcrun -sdk macosx10.11 clang++ -arch x86_64 -c pkgtest/tMatrixAssign.cpp -o
../../derived/maci64/obj/src/cgir_polly/pkgtest/tMatrixAssign.o -MMD -MF
../../derived/maci64/obj/src/cgir_polly/pkgtest/tMatrixAssign.d -MP -MT
../../derived/maci64/obj/src/cgir_polly/pkgtest/tMatrixAssign.o
-Iexport/include -I. -I../../src/include
-I../../derived/maci64/src/include -I../include -I../../include
-I../../derived/maci64/src/cgir_polly/include
-I../../derived/maci64/src/cgir_polly/
-isystem//mathworks/hub/3rdparty/R2017a/1971079/maci64/boost/include
-isystem//mathworks/hub/3rdparty/R2017a/1946655/maci64/cpp11compat/include
-isystem//mathworks/hub/3rdparty/R2017b/2334121/maci64/isl/include
-isystem//mathworks/hub/3rdparty/R2017b/2309377/maci64/jsoncpp/include
-isystem//mathworks/hub/3rdparty/R2017a/2105192/maci64/python2/include/python2.7
-isystem//mathworks/hub/3rdparty/R2017a/2101198/maci64/gmock/include/gmock
-isystem//mathworks/hub/3rdparty/R2017a/2101198/maci64/gmock/include/gtest
  -mmacosx-version-min=10.9
-DMODULE_VERSION_SYMBOL=libmwcgir_polly_version
-DMODULE_DATE_SYMBOL=libmwcgir_polly_build_date -Dmw_test_main=main
-DBOOST_CB_DISABLE_DEBUG -DBOOST_THREAD_FUTURE=unique_future
-DBOOST_SPIRIT_THREADSAFE -DPHOENIX_THREADSAFE
-DBOOST_SIGNALS_NO_DEPRECATION_WARNING
-DBOOST_MPL_CFG_NO_PREPROCESSED_HEADERS -DBOOST_MPL_LIMIT_VECTOR_SIZE=30
-DBOOST_MPL_LIMIT_MAP_SIZE=30 -DNEEDS_BOOST_UNIQUE_PTR=1
-DBUILDING_CGIR_POLLY -DGTEST_MW_USE_MW_NOT_EQUALS=1
-DGTEST_LINKED_AS_SHARED_LIBRARY=1 -DBUILDING_PKGTEST -O2 -stdlib=libc++
-pipe -D_REENTRANT -std=c++11 -g -DNDEBUG -Wextra -Wno-unused-parameter
-Wno-ignored-qualifiers -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual
-Woverloaded-virtual -Wnon-virtual-dtor -Wno-unused
-Wno-inconsistent-missing-override -Wno-parentheses-equality
-Wno-self-assign -Wno-tautological-compare -std=c++11 -stdlib=libc++
-ftemplate-depth-1024 -Werror

So yes, there's -Wl,-mark_dead_strippable_dylib + -Wl,-dead_strip +
-Wl,-dead_strip_dylibs.

- how exactly is your function declared? (e.g. if it's declared as
inline, or a template and unused then the compiler might not bother
emitting it)

It's not inline or a template. It's just a vanilla member function.

- could you verify (e.g. by running "objdump -t") that your function
is indeed present in the resulting binary?

macOS, so:

$ nm -a libmwcgir_polly.dylib | grep toString
00000000000050b0 T __ZNK2CG8analysis4SCOP8toStringEv
0000000000026f60 T __ZNK2CG8analysis8SCOPStmt8toStringEv

Does this mean that they're present?

Ram

I got around the problem using attribute used.

Ram

Interesting. So it looks like something was removing your function. I
don't know much about how linking works on mac, so I cannot say
whether that's supposed to be like that or not. Maybe one of the apple
folks will jump in and enlighten us.

cheers,
pavel

I believe if the function's visibility is hidden, then there is no need to create class methods that aren't used. I will check with our linker experts and get a more comprehensive reply for everyone later today.