I am trying to understand the best way to analyse a generated core dump of my crashed application, due to the fact that the Apalis board will run at the customer site, and the only way to understand the source of the problem will be the generated core dump file.
The generation of the core dump works fine, and it is created when the application crashes.
I have some problems in analysing the generated core dump.
What I am doing is the following, on my host computer (TmuControlApp is my running application on the Apalis):
nlanfran@U30Jc:/usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/arm-angstrom-linux-gnueabi$ ./arm-angstrom-linux-gnueabi-gdb /work/workspace/TmuControlApp/src/TmuControlApp /tmp/core-TmuControlApp-8-1000-1000-1232-1523349892 GNU gdb (GDB) 8.0 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-angstromsdk-linux --target=arm-angstrom-linux-gnueabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /work/workspace/TmuControlApp/src/TmuControlApp...done. warning: exec file is newer than core file. [New LWP 1232] warning: Could not load shared library symbols for . Do you need "set solib-search-path" or "set sysroot"? Core was generated by `/work/TmuControlApp'. Program terminated with signal SIGFPE, Arithmetic exception. #0 0x00265e28 in new_exp_0 (op=<optimized out>) at /usr/src/debug/glibc/2.26-r0/git/intl/plural.y:95 95 /usr/src/debug/glibc/2.26-r0/git/intl/plural.y: No such file or directory.
The cross compiled gdb is able to read the ARM executable (with debug symbols) and the generated core dump, and it gives me the correct reason of termination, but it is also looking for some shared libraries and I guess it is asking me to use the ‘set sysroot’ option. My ARM executable is compiled using static libraries, with:
/arm-angstrom-linux-gnueabi-g++ -march=armv7-a -mthumb -mfpu=neon -mfloat-abi=hard --sysroot=/usr/local/oecore-x86_64/sysroots/armv7at2hf-neon-angstrom-linux-gnueabi
I tried to follow the toradex web page related to analysing core dumps, and it says to do:
In oe-core/build/out-glibc/sysroot/colibri-t30: ../x86_64-linux/usr/bin/armv7ahf-vfp-neon-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gdb -ex 'set sysroot .' -ex 'core-file ./core-firefox-4-0-0-596-1402701200' usr/lib/firefox/firefox
but I am not sure I understand it correctly, as the instructions are for BSP releases prior to V 2.6.1.
Can somebody help me to do the last step (setting the sysroot when calling gdb) and be able to use backtrace and the full debug features of GDB ?
Thank you in advance !!