[lldb-dev] Why is function not present in target?

Greg Clayton via lldb-dev lldb-dev at lists.llvm.org
Fri Feb 10 09:04:22 PST 2017


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.

> On Feb 10, 2017, at 8:39 AM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> 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
> 
> On 10 February 2017 at 16:24, Ramkumar Ramachandra <artagnon at gmail.com> wrote:
>> I got around the problem using attribute used.
>> 
>> Ram
>> 
>> On Fri, Feb 10, 2017 at 9:02 AM Ramkumar Ramachandra <artagnon at gmail.com>
>> wrote:
>>> 
>>> Hi,
>>> 
>>> Pavel Labath <labath at google.com> wrote:
>>>> 
>>>> 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, at loader_path -Wl,-rpath, at loader_path/.
>>> -Wl,-rpath, at 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
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev



More information about the lldb-dev mailing list