> This is cause gdb puts software breakpoints as follows:
> 1.Fill up the memory with some predefined pattern (0x0000) od word length
> 2. Advance a counter by word length to jump over the filled bytes and
> remembers a counter value.
> 3. Save replaced code.
>
> When it hits a zero word , the simulator issues a signal - "interrupted with
> a
> reason breakpoint". When this signal issued, the real counter (PC) will be
> pointing the end of zeros. Then if finds a real code at saved address and
> restores memory. Stop execution and revert a counter backward by 2.
>
That is how I would expect it to work. However, my problem is that
the breakpoint is never hit, apparently due to the breakpoint being
set on the second word of a two word instruction.
Here is another example. I set breakpoints on 'main' and 'dummy', but
when I run, it hits the 'dummy' breakpoint.
.global main
main:
mov #0x1234,r4
add #1,r4
dummy:
add #2,r4
jmp main
bash$ msp430-gdb bkpt_test
GNU gdb 5.1.1
Copyright 2002 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-linux-gnu --target=msp430"...
(gdb) tar sim
Connected to the simulator.
(gdb) load bkpt_test
(gdb) b main
Breakpoint 1 at 0xfc42: file bkpt_test.S, line 4.
(gdb) b dummy
Breakpoint 2 at 0xfc46: file bkpt_test.S, line 7.
(gdb) r
Starting program: /export/home/galens/jobs/headon/sw/gdb_test/bkpt_test
Breakpoint 2, dummy () at bkpt_test.S:7
7 add #2,r4
Current language: auto; currently asm
(gdb)
thanks,
galen
