info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Wrong backtrace debugging armcc generated elf
3 views
Skip to first unread message
men...@gmail.com
Jun 29, 2016, 4:00:09 AM6/29/16
to
Hi all
I'm wondering if anyone can help on this subject.
I have reached a decent success in debugging a monolithic application running on a Cortex R4 with an embedded kernel, using Segger JLink debugger gdbserver and a windows gdb for ARM target, taken from the GNU ARM Embedded project. Everything under the umbrella and the help of GNU ARM Eclipse plugin.
This is the info from the gdb I use:
GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20160210-cvs
Copyright (C) 2015 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=i686-w64-mingw32 --target=arm-none-eabi".
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".
The application is compiled with armcc 5.0.1 (no room for changing it).
The info I can get from file on the elf target:
A2TK_PRJ.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped
As I have said everything works quite ok, I can control the target, break, walk through the code. What it is not working is the backtrace. What I see is that GDB gets a kind of confused, it seems it cannot understand correctly the current frame info and tries to access to some wrong memory location.
Is it anything I can fix with some settings or it is a known limitation when debugging armcc generated elf?
Thanks
Bye
I'm wondering if anyone can help on this subject.
I have reached a decent success in debugging a monolithic application running on a Cortex R4 with an embedded kernel, using Segger JLink debugger gdbserver and a windows gdb for ARM target, taken from the GNU ARM Embedded project. Everything under the umbrella and the help of GNU ARM Eclipse plugin.
This is the info from the gdb I use:
GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20160210-cvs
Copyright (C) 2015 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=i686-w64-mingw32 --target=arm-none-eabi".
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".
The application is compiled with armcc 5.0.1 (no room for changing it).
The info I can get from file on the elf target:
A2TK_PRJ.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped
As I have said everything works quite ok, I can control the target, break, walk through the code. What it is not working is the backtrace. What I see is that GDB gets a kind of confused, it seems it cannot understand correctly the current frame info and tries to access to some wrong memory location.
Is it anything I can fix with some settings or it is a known limitation when debugging armcc generated elf?
Thanks
Bye
0 new messages