debugging module within contrib folder using CLion + LLDB

[Charles Hutchins]

Hi All,

Put simply - I'm trying to debug a file within the contrib directory. This module has been created, configured and built successfully. It was then used in main.cc within the scratch, which also built successfully. However, when i try to debug or set breakpoints, I can set them in my main.cc file, but not in any module file which is in the contrib directory. 

Please Help? I'm guessing I have to tell CMake to add the symbols of the contrib folder into the main executable. But I don't have a degree in CMake so im unsure of how to do this or whether this is the correct course of action.

Many Thanks in advance for your responses,

Charles

[Gabriel Ferreira]

First thing first, try running 

ldd ./build/scratch/(ns3-dev|ns3.39)-main(-debug|-default|-relwithdebinfo)

If you don't have ldd, you can also use objdump -X program > out.txt then look for the linked libraries.

On MacOS, there is a differently utility called otool, but I don't remember the parameters to get the same result.

This will show if the contrib libraries have been linked to your program. If they weren't, then it explains the problem.

The second thing to do is double check if you are using the debug or default/relwithdebinfo build profiles.

If you are using release, optimized or minsizerel, there won't be any debugging symbols.

[Charles Hutchins]

Hi Gabriel,

Thank you for your fast response.

I am on MacOS, so I used "otool -L" which is (according to the help text):

"-L print shared libraries used" 

and this gave me:

@rpath/libns3.36.1-greydefense-aodv-debug.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libns3.36.1-greyattack-aodv-debug.dylib (compatibility version 0.0.0, current version 0.0.0)

@rpath/libns3.36.1-eaer-aodv-debug.dylib (compatibility version 0.0.0, current version 0.0.0)

which are the names of the modules in the contrib folder. Does this mean that the libraries are linked and should give me debugging symbols?

Cheers,

Charles

[Charles Hutchins]

P.S.

This is the CMake command I use to generate the binary - which does include the debug argument:
Applications/CLion.app/Contents/bin/cmake/mac/bin/cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_MAKE_PROGRAM=/Applications/CLion.app/Contents/bin/ninja/mac/ninja -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -DNS3_EXAMPLES=ON -G Ninja -S /Users/charles/CLionProjects/NS3/ns-allinone-3.36.1/ns-3.36.1 -B /Users/charles/CLionProjects/NS3/ns-allinone-3.36.1/ns-3.36.1/cmake-build-debug

[Gabriel Ferreira]

Yup, you should be able to debug normally with these. Not sure what is going on then. Did you give GDB a try?

[Charles Hutchins]

I have, I couldn't get gdb to run - but I could get lldb to run in command line. So i tried setting a breakpoint in the command line version. But whatever I type in, it doesn't seem to recognise the function or the file. Its really odd. Do you know of anyway of listing exactly what breakpoints one can set when you're in the lldb debugger? i assume its very similar to GDB.

There's also a command line utility called dsymutil, so I ran that with the -s argument and then grepped for "eaer" (part of the module name I'm interested in debugging) and it came back with all of this information:

Symbol table for: 'build/scratch/gametheoryscratch/EAER-Experiment/ns3.36.1-eaer-routing-debug' (x86_64)

[   101] 0000b569 1e (PEXT SECT    ) 01     0080   000000010001f3e0 '__ZN3ns310eaerHelperD1Ev'

[   109] 0000b6a2 1e (PEXT SECT    ) 01     0080   00000001000203b0 '__ZN3ns33PtrINS_8eaerAodv15RoutingProtocolEED1Ev'

[   578] 000143a4 1e (PEXT SECT    ) 01     0080   0000000100029070 '__ZN3ns310eaerHelperD2Ev'

[  1834] 0002fde9 1e (PEXT SECT    ) 01     0080   00000001000423d0 '__ZN3ns33PtrINS_8eaerAodv15RoutingProtocolEEC1EPS2_'

[  1835] 0002fe1d 1e (PEXT SECT    ) 01     0080   0000000100042400 '__ZN3ns33PtrINS_8eaerAodv15RoutingProtocolEEC2EPS2_'

[  1836] 0002fe51 1e (PEXT SECT    ) 01     0080   0000000100042470 '__ZN3ns33PtrINS_8eaerAodv15RoutingProtocolEED2Ev'

[  2054] 00035a75 0e (     SECT    ) 01     0000   0000000100046590 '__GLOBAL__sub_I_eaer_routing.cc'

[  2356] 00037afe 64 (N_SO         ) 00     0000   0000000000000000 'eaer-routing.cc'

[  2357] 00037b0e 66 (N_OSO        ) 03     0001   0000000064d3e76d '/Users/charles/CLionProjects/NS3/ns-allinone-3.36.1/ns-3.36.1/cmake-build-debug/scratch/CMakeFiles/scratch_gametheoryscratch_EAER-Experiment_eaer-routing.dir/gametheoryscratch/EAER-Experiment/eaer-routing.cc.o'

[  2931] 00039d32 24 (N_FUN        ) 01     0000   000000010001f3e0 '__ZN3ns310eaerHelperD1Ev'

[  3015] 0003a20c 24 (N_FUN        ) 01     0000   0000000100020060 '__ZN3ns311DynamicCastINS_8eaerAodv15RoutingProtocolENS_19Ipv4RoutingProtocolEEENS_3PtrIT_EERKNS4_IT0_EE'

[  3019] 0003a274 24 (N_FUN        ) 01     0000   0000000100020100 '__ZN3ns33PtrINS_8eaerAodv15RoutingProtocolEEptEv'

[  3035] 0003a346 24 (N_FUN        ) 01     0000   00000001000203b0 '__ZN3ns33PtrINS_8eaerAodv15RoutingProtocolEED1Ev'

[  4943] 00042e09 24 (N_FUN        ) 01     0000   0000000100029070 '__ZN3ns310eaerHelperD2Ev'

[ 10359] 00060de3 24 (N_FUN        ) 01     0000   00000001000423d0 '__ZN3ns33PtrINS_8eaerAodv15RoutingProtocolEEC1EPS2_'

[ 10363] 00060e17 24 (N_FUN        ) 01     0000   0000000100042400 '__ZN3ns33PtrINS_8eaerAodv15RoutingProtocolEEC2EPS2_'

[ 10367] 00060e4b 24 (N_FUN        ) 01     0000   0000000100042430 '__ZNK3ns33PtrINS_8eaerAodv15RoutingProtocolEE7AcquireEv'

[ 10371] 00060e83 24 (N_FUN        ) 01     0000   0000000100042470 '__ZN3ns33PtrINS_8eaerAodv15RoutingProtocolEED2Ev'

[ 11303] 00067339 24 (N_FUN        ) 01     0000   0000000100046590 '__GLOBAL__sub_I_eaer_routing.cc'

[ 11727] 0000092b 0f (     SECT EXT) 01     0080   0000000100020060 '__ZN3ns311DynamicCastINS_8eaerAodv15RoutingProtocolENS_19Ipv4RoutingProtocolEEENS_3PtrIT_EERKNS4_IT0_EE'

[ 11808] 00002380 0f (     SECT EXT) 01     0080   0000000100020100 '__ZN3ns33PtrINS_8eaerAodv15RoutingProtocolEEptEv'

[ 11862] 00003275 0f (     SECT EXT) 01     0080   0000000100042430 '__ZNK3ns33PtrINS_8eaerAodv15RoutingProtocolEE7AcquireEv'

[ 12057] 00006f77 01 (     UNDF EXT) 00     1400   0000000000000000 '__ZN3ns310eaerHelperC1Ev'

[ 12266] 0000981f 01 (     UNDF EXT) 00     1400   0000000000000000 '__ZTIN3ns38eaerAodv15RoutingProtocolE'

[ 12282] 00009a22 01 (     UNDF EXT) 00     1400   0000000000000000 '__ZTVN3ns310eaerHelperE'

bare in mind that eaer-routing.cc is the file thats in the scratch and I have been able to debug that successfully. Not sure what the rest of this information means. If anything at all.

Do you have anymore tips for me? Or am i stuck to commenting code in/out until I find the issue?

Cheers,

Charles

[Gabriel Ferreira]

I have no idea how to debug stuff on the command line. Using CLion, I'd suggest adding the breakpoints to your scratch file on the lines where you instantiate objects defined in these contrib modules. Then step in, to go inside the called function (e.g. a constructor). It was supposed to work, unless you had built with relwithdebinfo, where some of these could get inlined during the optimization phase.

The dsym output is showing the mangled C++ names for functions, types, constructors, destructors, etc.
Everything seems normal. UNDF EXT are external symbols that get resolved when starting the program. The dynamic linker loads the shared libraries, tabulate their exported symbols and fix up indirections to the proper addresses. 

If that doesn't work, I'd say to test with Xcode. Use the following to create the project.

./ns3 config -G Xcode

[Charles Hutchins]

Hey Gabriel,

So Xcode gave me an error when i tried to use it in the debug settings. So I tried compiling exactly the same code on a Linux PC: CLion with GDB (non-ideal as its a desktop, but what can you do). And it worked first time, all breakpoints are hit in the contrib files. Not sure what im doing wrong but i suspect its a silly MacOS thing. I did spot a few warnings pop up briefly regarding a version mismatch between linkers. Apparently this can happen when you update your Mac. I tried deleting the cache, build directory and cmake directory, recompiled everything but the warning remained and unfortunately it gave the same result.

Thank you for trying to solve this with me, but it looks like Linux wins again. It would be interesting to know if anyone else on this forum has had the same issue (or not) with Mac.

Thanks again,

Charles