From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106712 invoked by alias); 29 Mar 2016 17:17:17 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 106613 invoked by uid 89); 29 Mar 2016 17:17:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=HTo:D*atmel.com, presenting, ack, tripped X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 29 Mar 2016 17:17:13 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id CF452C049E17; Tue, 29 Mar 2016 17:17:11 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2THH8md017290; Tue, 29 Mar 2016 13:17:08 -0400 Subject: Re: [patch, avr, pr19401] Update PC after break To: Pitchumani Sivanupandi References: <20160323141426.GA10252@CHELT0346> <56F2AAC3.8000101@redhat.com> <20160324134033.GA10892@CHELT0346> Cc: gdb-patches@sourceware.org, chertykov@gmail.com, troth@openavr.org, vapier@gentoo.org, Senthil_Kumar.Selvaraj@atmel.com From: Pedro Alves Message-ID: <56FAB894.3070600@redhat.com> Date: Tue, 29 Mar 2016 17:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160324134033.GA10892@CHELT0346> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-03/txt/msg00522.txt.bz2 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