[patch, avr, pr19401] Update PC after break

[Pedro Alves]

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