From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23281 invoked by alias); 24 Mar 2016 13:40:53 -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 23209 invoked by uid 89); 24 Mar 2016 13:40:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*Ad:D*gentoo.org, HCC:D*gmail.com, transfer, Transfer X-HELO: eusmtp01.atmel.com Received: from eusmtp01.atmel.com (HELO eusmtp01.atmel.com) (212.144.249.243) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 24 Mar 2016 13:40:44 +0000 Received: from HNOCHT01.corp.atmel.com (10.161.30.161) by eusmtp01.atmel.com (10.161.101.31) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 24 Mar 2016 14:40:34 +0100 Received: from CHELT0346 (10.161.30.18) by HNOCHT01.corp.atmel.com (10.161.30.161) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 24 Mar 2016 14:40:39 +0100 Date: Thu, 24 Mar 2016 13:40:00 -0000 From: Pitchumani Sivanupandi To: Pedro Alves CC: , , , , Subject: Re: [patch, avr, pr19401] Update PC after break Message-ID: <20160324134033.GA10892@CHELT0346> References: <20160323141426.GA10252@CHELT0346> <56F2AAC3.8000101@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <56F2AAC3.8000101@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00494.txt.bz2 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. > > 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. Update test case and gdb log: volatile int a = 12; int main () { a = 0x0123; while (1) a++; return 0; } avr-gcc sim1.c -mmcu=atmega2560 -g -o sim1.elf Reading symbols from sim1.elf...done. (gdb) target sim Connected to the simulator. (gdb) load Loading section .data, size 0x2 lma 0x146 Loading section .text, size 0x146 lma 0x0 Start address 0x0 Transfer rate: 2624 bits in <1 sec. (gdb) b main Breakpoint 1 at 0x122: file sim1.c, line 5. (gdb) run Starting program: /home/zero/build/avr-trunk/sim1.elf Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000124 in main () at sim1.c:5 5 a = 0x0123; (gdb) disassemble Dump of assembler code for function main: 0x0000011a <+0>: push r28 0x0000011c <+2>: push r29 0x0000011e <+4>: in r28, 0x3d ; 61 0x00000120 <+6>: in r29, 0x3e ; 62 0x00000122 <+8>: ldi r24, 0x23 ; 35 => 0x00000124 <+10>: ldi r25, 0x01 ; 1 0x00000126 <+12>: sts 0x0201, r25 0x0000012a <+16>: sts 0x0200, r24 0x0000012e <+20>: lds r24, 0x0200 0x00000132 <+24>: lds r25, 0x0201 0x00000136 <+28>: adiw r24, 0x01 ; 1 0x00000138 <+30>: sts 0x0201, r25 0x0000013c <+34>: sts 0x0200, r24 0x00000140 <+38>: rjmp .-20 ; 0x12e End of assembler dump. (gdb) si 0x00000126 5 a = 0x0123; (gdb) p $r24 $1 = 0 (gdb) p $r25 $2 = 1 (gdb) > 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. Regards, Pitchumani