thank You all for your input. I've been playing around with all different
kinds of settings for -g and -O, without success.
Today I installed a fresh and up to date version of gcc, binutils, gdb and
newlib, this time with -target=arm-none-eabi instead of arm-elf and everything
is running fine again. I now compile with -g3 and -Os.
On 08/03/2014 08:21, Phil Young wrote: >
>
> Using –g3 you are compiling with the optomizer turned on, in which
> case you enable a variety of optimizations that mean functions may for
> example get inlined, code may even be generated by the linker ( Not sure
> whether GCC supports this but many toolchains do ).
>
>
>
> Try compiling with –g0, if not for the whole project then at least
for
> the parts you want to debug.
>
-g has nothing to do with optimisation, and everything to do with how
much debugging information is available. The existing setting of -g3
will provide maximum debugging information, so changing this to -g0
will, if anything, make the problem worse.
Optimisation is controlled by -O[level], which can be set to -O0 to -O3
(and -Os) where the higher the number the higher the optimisation level.
As far as I can see you do not specify a -O level at all, in which case
the default is 0, which is what you want for easy debugging. You may
want to add -O0 to your command line just to make sure. Otherwise the
problem lies elsewhere (are you sure the object being debugged is that
actually built? Are you sure the build was successful?).
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 107000 downloads in 2013.
Using –g3 you are compiling with the optomizer turned on, in which case
you enable a variety of optimizations that mean functions may for example get
inlined, code may even be generated by the linker ( Not sure whether GCC
supports this but many toolchains do ).
Try compiling with –g0, if not for the whole project then at least for the
parts you want to debug.
Regards
Phil.
From: l... [mailto:l...] On Behalf Of l...@gmx.de
Sent: 07 March 2014 16:18
To: l...
Subject: [lpc2000] arm-elf-gdb is confused with source files.
Hello,
I am having a problem debugging my code on a LPC2387. The code works fine, but I
can't debug.
Somehow arm-elf-gdb is confused by the source files. When for example I try to
"list myfunc()", gdb shows the wrong file or doesn't show anything at all
("No source available").
The same with breakpoints. When I set a breakpoint in a function other that
main(), the program stops, but gdb jumps to the wrong source file or
doesn't jump at all.
Debugging main.c somehow works. Breakpoints are handled correct and a "list
main" gives the correct result.
Any suggestions? I have tried to solve this for days now, but haven't found
a solution.
Regards,
Laurenz
Reply by laur...@gmx.de●March 8, 20142014-03-08
Hello,
I am having a problem debugging my code on a LPC2387. The code works fine, but
I can't debug.
Somehow arm-elf-gdb is confused by the source files. When for example I try to
"list myfunc()", gdb shows the wrong file or doesn't show anything at all
("No source available").
The same with breakpoints. When I set a breakpoint in a function other that
main(), the program stops, but gdb jumps to the wrong source file or
doesn't jump at all.
Debugging main.c somehow works. Breakpoints are handled correct and a "list
main" gives the correct result.
Here is my setup:
-I have multiple files, some in a subdirectory.
-arm-elf-gcc 4.1.1
-arm-elf-gdb 7.7
-newlib 1.14
-I debug the target using openOCD 1.0