From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88235 invoked by alias); 23 Mar 2016 14:40:09 -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 88206 invoked by uid 89); 23 Mar 2016 14:40:09 -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_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=HTo:D*atmel.com, behaving 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; Wed, 23 Mar 2016 14:40:07 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 08A52C049D68; Wed, 23 Mar 2016 14:40:06 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2NEe3EI029880; Wed, 23 Mar 2016 10:40:04 -0400 Subject: Re: [patch, avr, pr19401] Update PC after break To: Pitchumani Sivanupandi , gdb-patches@sourceware.org, chertykov@gmail.com References: <20160323141426.GA10252@CHELT0346> Cc: troth@openavr.org, senthil_kumar.selvaraj@atmel.com From: Pedro Alves Message-ID: <56F2AAC3.8000101@redhat.com> Date: Wed, 23 Mar 2016 14:40:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160323141426.GA10252@CHELT0346> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-03/txt/msg00470.txt.bz2 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? > 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? Is the simulator behaving differently from real hardware? Are existing stubs rewinding the PC themselves, or using a different breakpoint instruction (by implementing the z/Z packets)? Thanks, Pedro Alves