Sysprogs forums › Forums › VisualGDB › VisualGDB can't debug parts of a library
- This topic has 7 replies, 2 voices, and was last updated 8 years, 9 months ago by support.
-
AuthorPosts
-
January 6, 2016 at 10:43 #7437John24Participant
Hello,
I’m having an odd issue. In my Project I am using a couple of libraries: PCL, OpenCV and Exiv2. The project is based on the use of Raspberry Pi and the code is compiled locally on my machine and the executable is run on the Raspberry Pi.
In particular I am actually making some changes to PCL library and what is odd that some files of the library I can amend and debug while some files I can’t. The ones I can’t breakpoints are never hit and actually I don’t think the file is even being compiled, as if I make any errors compilation still goes through.
Would this be an issue with Visual studio 2013 or my VisualDGB setup?
January 8, 2016 at 05:32 #7444supportKeymasterHi,
Most likely you are either not deploying your library or are using the wrong symbols. Please ensure that the modified version of the library ends up both:
- On your Raspberry Pi
- In the sysroot directory of your toolchain. You can check the exact path by running the “info shared” command in the GDB Session window
January 22, 2016 at 13:00 #7506John24ParticipantOk I have made sure that modified library code is in both my PC and Raspberry Pi. But it seems that the project is only using already compiled library .so files instead of my changed files.
- This reply was modified 8 years, 9 months ago by John24.
January 23, 2016 at 05:49 #7513supportKeymasterHi,
You can diagnose this by adding a new function to your library (e.g. testfunc()), calling it from your code and then checking whether the library on Raspberry Pi contains the new function by running the following command:
nm <library path> | grep <function name>
You can find out the path of the library loaded into your application by running the “info shared” command in the GDB Session window.
January 25, 2016 at 10:40 #7525John24ParticipantHi Bazis,
Thanks for your reply 🙂
So running “info shared” gave me the Shared Object Library locations and I found the libpcl_filters.so file.
Running “nm libpcl_filters.so | grep TestFunc1()” gave result of “no symbols” even when I tried to find a library function I had “no symbols result”. I assume I am doing something wrong.
Because I am cross compiling on my machine and sending just the binaries to the Pi I assumed that files only on my machine need to be changed.
I do apologise if I am doing this all wrong.
January 25, 2016 at 21:48 #7535supportKeymasterHi,
No worries, we’ll help you get it right.
First of all, please use just the function name without brackets (e.g. TestFunc, not TestFunc()). Then if it does not help, run “nm <library name>” without grep to see if the library symbols can be viewed at all.
If ‘nm’ does not provide reasonable output, you can also run “objdump -t <library name>” to list the symbols using another method.
You can also run “stat <library name>” to see the modification time of the library. If you are using the old version you should clearly see it from the modification time.
Remember, your code inside the library must actually call the TestFunc(), as otherwise it will be discarded by the linker as an unused function.”
If nothing helps, please share the output of the nm and objdump commands here.
January 26, 2016 at 10:40 #7542John24ParticipantHi Baxis,
Thanks for the replies. Thanks to you I was able to spot what the issue was. At the end of library source files for PCL there is a #ifdef PCL_NO_PRECOMPILE statement which will not recompile the code if changed unless PCL_NO_PRECOMPILE is defined in the code.
So it’s all good and working now 🙂 Thanks for your help, I really appreciate it!
January 27, 2016 at 22:12 #7555supportKeymasterHi,
Good to know it works, if you encounter any other problems, feel free to create a new topic.
-
AuthorPosts
- You must be logged in to reply to this topic.