Hi Kurt,
KFranke wrote:
Arnd-Hendrik,
I do not have any breakpoints set where gdb stops. In the example, I set only
one breakpoint (on line 105), then tried to step over the function call
occuring a couple of lines later. Instead, gdb stopped at the beginning of the
function, line 22.
What optimization do you use? I don't know how far gcc goes in these
things but (at least with other targets/compilers) you can often see
optimizations like that:
getStatus:
bla a,a
bli i,i
blubb i
blubb o
ret
otherFunction:
foo o,o
bar a,r
blubb i
blubb o
ret
optimized to:
getStatus:
bla a,a
bli i,i
jmp labelwherebreakpointcanbeplaced
otherFunction:
foo o,o
bar a,r
labelwherebreakpointcanbeplaced:
blubb i
blubb o
ret
As you can see in this case it is possible to reach a breakpoint even
where it is not positioned explicitly. I don't know your code but maybe
you can step (or stepi) into that function and have a look at the
disassembled code where it runs into that breakpoint.
Another possibility is the following combination:
load,
set breakpoint,
debug,
change,
recompile,
erase,
load,
set breakpoint,
debug,
debugger still may have both breakpoints and runs into the old one (same
position but shifted code). I have had this seldomly but a few times
with other debuggers but in my opinion the other one is more likely than
this one.
Regards
Arnd-Hendrik
Sincerely,
Kurt
-----Original Message-----
From: mspgcc-users-ad...@lists.sourceforge.net
[mailto:mspgcc-users-ad...@lists.sourceforge.net]on Behalf Of
Arnd-Hendrik Mathias
Sent: Thursday, October 07, 2004 4:22 PM
To: mspgcc-users@lists.sourceforge.net
Subject: Re: [Mspgcc-users] gdb 'next' not working as expected
Hi Kurt,
'next' never jumps over some functions. It runs through that function up
to the next line after the function call. No matter if you run, next,
step, nexti or stepi you will always execute the same code.
When reaching a breakpoint program execution will stop anyway. So the
breakpoint interrupts program execution before reaching the next line of
code after that where you gave the next command. This is what you
usually expect from a breakpoint for otherwise the next line stops
anyway (with next) so you wouldn't need any breakpoints.
In your example first next is OK, while the second next is interrupted
by running into a breakpoint. That's why you assumingly put it there.
I'm not sure but I hope I met your problem.
Best regards
Arnd-Hendrik
KFranke wrote:
Hello,
I'm new to mspgcc and am having some problems with the gdb.
'next' commands always seem to take me inside function calls.
I get the same behavior using the msp430-gdbproxy and using
the 'sim' target.
I'm running binaries from mspgcc-20040723.exe from a cygwin
shell on a w2k machine.
The program was compiled with:
$ msp430-gcc -g -o test test.c -mmcu=msp430x169
gdb output follows. The last 'n' command enters the get_status()
function instead of breaking on the next line of main().
Thanks in advance,
Kurt
--- msp430-gdb output ---
$ msp430-gdb test
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-cygwin --target=msp430"...
(gdb) set remoteaddresssize 64
(gdb) set remotetimeout 999999
(gdb) target remote localhost:2000
Remote debugging using localhost:2000
0x00001100 in _reset_vector__ ()
(gdb) monitor erase
Erasing target flash - all... Erased OK
(gdb) load test
Loading section .text, size 0x3c2 lma 0x1100
Loading section .data, size 0x4 lma 0x14c2
Loading section .vectors, size 0x20 lma 0xffe0
Start address 0x1100, load size 998
Transfer rate: 1596 bits/sec, 199 bytes/write.
(gdb) b test.c:105
Breakpoint 1 at 0x1398: file test.c, line 105.
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
main () at test.c:105
105 U0CTL &= ~SWRST;
(gdb) n
107 status = get_status();
(gdb) n
Program received signal SIGTRAP, Trace/breakpoint trap.
get_status () at test.c:22
22 {
(gdb)
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
