[patch, avr, pr19401] Update PC after break

[Pitchumani Sivanupandi]

On Tuesday 29 March 2016 10:47 PM, Pedro Alves wrote:
> 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.
>
Hi Pedro,

Thanks for the comments. Sorry for the delay in responding.

AVR target stops when executes break insn. It is the gdb-server that
rewrites PC if target executes break insn. Checked atmel backend
and avarice; it restores the content in the breakpoint location (i.e.
replaces break insn with original content).

Simulator for avr target doesn't update PC when break insn is executed.
It used to do that, but it was broken after commit 9943d3185.
Commented in bugzilla.
https://sourceware.org/bugzilla/show_bug.cgi?id=19401

IMHO, it is the simulator needs fix, not the gdb. I'll send out patch 
for simulator.

Thanks.

Regards,
Pitchumani