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>
- Cc: gdb-patches at sourceware dot org, chertykov at gmail dot com, troth at openavr dot org, vapier at gentoo dot org, Senthil_Kumar dot Selvaraj at atmel dot com
- Date: Tue, 29 Mar 2016 18:17:08 +0100
- Subject: Re: [patch, avr, pr19401] Update PC after break
- Authentication-results: sourceware.org; auth=none
- References: <20160323141426 dot GA10252 at CHELT0346> <56F2AAC3 dot 8000101 at redhat dot com> <20160324134033 dot GA10892 at CHELT0346>
On 03/24/2016 01:40 PM, Pitchumani Sivanupandi wrote:
On Wed, Mar 23, 2016 at 02:40:03PM +0000, Pedro Alves wrote:
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?
This test case was working till gdb-7.9. May be a regression from 7.10.
Did you do a git bisect to find out why this changed?
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?
copy-paster error. SIGTRAP occurs for this case.
Ack.
Is the simulator behaving differently from real hardware? Are existing
Yes, it seems. I checked atmega2560 device with avarice, avr-dragon and
avr-gdb. PC is 0x122 when target hits breakpoint, as expected.
stubs rewinding the PC themselves, or using a different breakpoint
instruction (by implementing the z/Z packets)?
Sorry, I don't understand what you mean by existing stubs.
The server side of the GDB remote connection when you do live
debugging with those devices.
So the question remains -- what does the AVR do when it
executes that breakpoint instruction?
- Does the PC point to the breakpoint instruction and thus
the SIM is wrong.
- Or does the PC point after the breakpoint instruction, which
suggests that stubs are decrementing the PC themselves before
presenting the stop to gdb, otherwise they'd have tripped
on this.
This matters because getting the decrement wrong when the target
does the decrement itself is also bad. If you have two
consecutive 2-byte instructions, and you set breakpoints on both,
and the code flow jumps to the second instruction, GDB will decrement
the PC incorrectly:
ADDR1 INSN1 << breakpoint 1
ADDR2 INSN1 << breakpoint 2
... ...
ADDRn jmp ADDR2
So the stub reports "stop at ADDR2", and then GDB misunderstands that
as meaning "stop at ADDR1 + 2", and incorrectly decrements the PC to
"ADDR1".
Thanks,
Pedro Alves