This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch, avr, pr19401] Update PC after break
- From: Pedro Alves <palves at redhat dot com>
- To: Pitchumani Sivanupandi <pitchumani dot s at atmel dot com>, gdb-patches at sourceware dot org, chertykov at gmail dot com
- Cc: troth at openavr dot org, senthil_kumar dot selvaraj at atmel dot com
- Date: Wed, 23 Mar 2016 14:40:03 +0000
- Subject: Re: [patch, avr, pr19401] Update PC after break
- Authentication-results: sourceware.org; auth=none
- References: <20160323141426 dot GA10252 at CHELT0346>
On 03/23/2016 02:14 PM, Pitchumani Sivanupandi wrote:
> avr-gdb doesn't seem to be rewinding the PC after break. If a breakpoint
> is at four byte instruction, it resumes from the middle of the
> instruction. This caused the target to reject the next (half) instruction
> as illegal. In case of breakpoint at two byte instruction, it resumes from
> the the next instruction. Instruction at breakpoint location was skipped
> as the PC was rewinded after break.
>
> Test case in PR19401 is the example for the first situation. Below
> example is for second situation.
How was this not noticed before?
> command line: avr-gcc test.c -mmcu=atmega2560 -g -o test.elf
> avr-gdb test.elf
> (gdb) target sim
> (gdb) load
> (gdb) b main
> (gdb) run
> 0x00000124 in main () at sim1.c:5
I would expect to see mention of a SIGTRAP here, and for all
breakpoints, as gdb won't be able to map the current PC address
with any GDB breakpoint. Doesn't that happen?
Is the simulator behaving differently from real hardware? Are existing
stubs rewinding the PC themselves, or using a different breakpoint
instruction (by implementing the z/Z packets)?
Thanks,
Pedro Alves