Cross-compiling dune with debug symbols for GDB

[Kristian Klausen]

Hi,

We are developing a driver which we would like to debug with gdb on target (a beaglebone black, with Glued).

However, when we are cross-compiling, the debug symbols seems to not be generated, even with the Cmake switches DEBUG and PROFILE set to true. Thus, when we run gdb on target, it can't find the debug symbols.

I have noticed that the -g flags seems to be removed in the cmake/Toolchain.cmake file, and we have tried re-adding the the flag manually in the CMakeLists.txt-file with no success.

Any tips to resolve this?

Best regards,
Kristian Klausen

[Pedro Gonçalves]

Hi,

What is the output of the command "show sysroot" (to be executed in gdb of target)?

The output has to be " system root is "/". ", if not, try execute the command " set sysroot /", to set the path of file system/lib.

Best Regards

Pedro Gonçalves ( LSTS - FEUP )

--
www.github.com/LSTS/
www.lsts.pt
---
You received this message because you are subscribed to the Google Groups "LSTS Toolchain" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lsts-toolchain+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/lsts-toolchain.
To view this discussion on the web visit https://groups.google.com/d/msgid/lsts-toolchain/5d434aac-0d85-4af1-bc4f-a545adc1b92c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Morten Fyhn Amundsen]

Thank you,

'show sysroot' returns '$HOME/uavlab/glued/ntnu-b2xx/toolchain/armv7-lsts-linux-gnueabihf/sysroot'. Setting it to '/' with 'set sysroot /' does not seem to help finding the symbol tables.

We are however attempting to run gdb on the BeagleBone without using gdbserver. What we want is the dune executable to be compiled with the necessary symbol tables for debugging locally on the BeagleBone. I don't think it's necessary for us to run gdb remotely.

I noticed now that the dune executable seems to be stripped, which I assume implies that the problem is that the symbol tables do not exist when we run gdb rathen than that it cannot load them:

➜ file dune

dune: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, stripped

(I'm working with Kristian on this.)

Best,

Morten

tirsdag 1. august 2017 20.25.30 UTC+2 skrev Pedro Gonçalves følgende:

Hi,

What is the output of the command "show sysroot" (to be executed in gdb of target)?

The output has to be " system root is "/". ", if not, try execute the command " set sysroot /", to set the path of file system/lib.

Best Regards

Pedro Gonçalves ( LSTS - FEUP )

2017-08-01 18:34 GMT+01:00 Kristian Klausen <kkn...@gmail.com>:

Hi,

We are developing a driver which we would like to debug with gdb on target (a beaglebone black, with Glued).

However, when we are cross-compiling, the debug symbols seems to not be generated, even with the Cmake switches DEBUG and PROFILE set to true. Thus, when we run gdb on target, it can't find the debug symbols.

I have noticed that the -g flags seems to be removed in the cmake/Toolchain.cmake file, and we have tried re-adding the the flag manually in the CMakeLists.txt-file with no success.

Any tips to resolve this?

Best regards,
Kristian Klausen

--
www.github.com/LSTS/
www.lsts.pt
---
You received this message because you are subscribed to the Google Groups "LSTS Toolchain" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lsts-toolchai...@googlegroups.com.

[José Braga]

Hi,

Although I am quite ignorant in these matters I do believe the keyword difference is seeing:

ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, with debug_info, not stripped

at least, there are no symbols found with files "not stripped" but that lack the keyword "with debug_info"

Can you clear all content, and run cmake with -DDEBUG=1 to check?

The description above is what I got when compiling with ntnu-b2xx toolchain with -DDEBUG=1

Kind Regards,

José Braga

____________________

jbr...@oceanscan-mst.com

www.oceanscan-mst.com

To unsubscribe from this group and stop receiving emails from it, send an email to lsts-toolchain+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/lsts-toolchain.

To view this discussion on the web visit https://groups.google.com/d/msgid/lsts-toolchain/1b5a228e-f676-4190-aec6-2d2a313f2065%40googlegroups.com.

[José Braga]

Moreover you should be able to change default rules for that architecture in cmake/Compiler.cmake.

In LAUVs (arch x86) we have Debug option enabled by default which I believe is set here:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -g")

José Braga

____________________

jbr...@oceanscan-mst.com

www.oceanscan-mst.com

[Morten Fyhn Amundsen]

That seems to have done the trick.

We ended up removing 

set(CPACK_STRIP_FILES "bin/dune"

in dune/CMakeLists.txt, and adding

      if(CMAKE_BUILD_TYPE MATCHES "Debug")

        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -g")

        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -g")

      endif(CMAKE_BUILD_TYPE MATCHES "Debug")

under '# GNU C Compiler' in dune/cmake/Compiler.cmake, in addition to running

cmake -DDEBUG=1 -DCROSS=/home/mortenfyhn/dune/glued/ntnu-b2xx/toolchain/bin/armv7-lsts-linux-gnueabihf- ../dune

in the target build folder. Then, running gdb on the BeagleBone successfully loads the symbol table.

Running 'file dune' does not print 'with debug_info', however, but running 'objdump --syms dune | grep debug' finds a bunch of debug frames.

But running gdb locally on the BBB does not work as it has no access to the source code. Running remotely gives the 'Remote 'g' packet reply is too long' error seemingly due to the different architectures. We're looking into it.

[José Braga]

The way I've used it in the past is to run in on a laptop calling the gdb on the glued toolchain, e.g:

~/glued/ntnu-b2xx/toolchain/bin/armv7-lsts-linux-gnueabihf-gdb dune

Inside I get:

Reading symbols from dune...done.

Not sure if this is enough, but I guess it should be... To be honest, I've only used gdb to find the

cause of a coredump (I have no BBB with me to create one), so I am just assuming it should be enough :)

José Braga

____________________

jbr...@oceanscan-mst.com

www.oceanscan-mst.com

--

www.github.com/LSTS/
www.lsts.pt
---
You received this message because you are subscribed to the Google Groups "LSTS Toolchain" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lsts-toolchain+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/lsts-toolchain.

To view this discussion on the web visit https://groups.google.com/d/msgid/lsts-toolchain/b465fe45-4e36-4393-82e4-3ebf2f69555a%40googlegroups.com.

[José Braga]

Forgot to mention, in the command above, dune is the bbb' armv7 binary..

José Braga

____________________

jbr...@oceanscan-mst.com

www.oceanscan-mst.com

[Morten Fyhn Amundsen]

Thank you for the help, both.

Eventually, we got everything up and running by doing:

• Upgrade gdb on the BBB to 7.10.1 (the local computer runs 7.11.1).
• Compile gdb with expat.
• Comment out 'set(CPACK_STRIP_FILES "bin/dune")' in dune/CMakeLists.txt to make sure debug symbols are not stripped.

[Kristoffer Gryte]

Hi,

I know its old-ish, but for future reference: I also had to include "-DCMAKE_BUILD_TYPE=Debug" to cmake when building.

Kristoffer