[Bug breakpoints/16703] New: The program breaks at the next instruction when issuing a memory breakpoint on AVR8.

[Bug breakpoints/16703] New: The program breaks at the next instruction when issuing a memory breakpoint on AVR8.

[pierre.langlois at embecosm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16703

            Bug ID: 16703
           Summary: The program breaks at the next instruction when
                    issuing a memory breakpoint on AVR8.
           Product: gdb
           Version: 7.7
            Status: NEW
          Severity: normal
          Priority: P2
         Component: breakpoints
          Assignee: unassigned at sourceware dot org
          Reporter: pierre.langlois at embecosm dot com

Created attachment 7469
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7469&action=edit
Simple program ran on the ATxmega256a3b chip

When setting breakpoints on AVR, using gdb against the simulator models, using
the ATxmega256a3u, the program counter needs to be decremented after a
breakpoint is hit. This only happens with memory breakpoints.

------------------------------------------------------------------------------

GNU gdb (AVR 8-bit toolchain (built 20140310)) 7.7.50.20140313-cvs
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=avr".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.atmel.com>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) set re\b^[[K\b^[[Kdebug remote 1
(gdb) target remote :51000
Remote debugging using :51000
0x0000020e in ?? ()
(gdb) file atxmega-test.elf 
A program is being debugged already.
Are you sure you want to change the file? (y or n) Reading symbols from
atxmega-test.elf...done.
(gdb) load
Loading section .text, size 0x22e lma 0x0
Start address 0x0, load size 558
Transfer rate: 544 KB/sec, 186 bytes/write.
(gdb) monitor reset
(gdb) break main
Breakpoint 1 at 0x204: file main.c, line 7.
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000206 in main () at main.c:7
7      PORTR.DIRSET = 3;
(gdb) break *(@code void *) 0x106
Breakpoint 2 at 0x20c: file main.c, line 8.
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000020e in main () at main.c:8
8      PORTR.OUTSET = 1;
(gdb) p/x $pc
$1 = 0x20e
(gdb) info breakpoints 
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x00000204 in main at main.c:7
2       breakpoint     keep y   0x0000020c in main at main.c:8
(gdb) q
A debugging session is active.

    Inferior 1 [Remote target] will be killed.

Quit anyway? (y or n)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From gdb-prs-return-15390-listarch-gdb-prs=sources.redhat.com@sourceware.org Fri Mar 14 10:09:01 2014
Return-Path: <gdb-prs-return-15390-listarch-gdb-prs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb-prs@sources.redhat.com
Received: (qmail 3650 invoked by alias); 14 Mar 2014 10:09:00 -0000
Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-prs.sourceware.org>
List-Subscribe: <mailto:gdb-prs-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-prs/>
List-Post: <mailto:gdb-prs@sourceware.org>
List-Help: <mailto:gdb-prs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: gdb-prs-owner@sourceware.org
Delivered-To: mailing list gdb-prs@sourceware.org
Received: (qmail 3625 invoked by uid 48); 14 Mar 2014 10:08:59 -0000
From: "pierre.langlois at embecosm dot com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug breakpoints/16703] The program breaks at the next instruction
 when issuing a memory breakpoint on AVR8.
Date: Fri, 14 Mar 2014 10:09:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: breakpoints
X-Bugzilla-Version: 7.7
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pierre.langlois at embecosm dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: pierre.langlois at embecosm dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to
Message-ID: <bug-16703-4717-SQX92X8x9W@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-16703-4717@http.sourceware.org/bugzilla/>
References: <bug-16703-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-q1/txt/msg00398.txt.bz2
Content-length: 472

https://sourceware.org/bugzilla/show_bug.cgi?id\x16703

Pierre Langlois <pierre.langlois at embecosm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |pierre.langlois at embecosm dot co
                   |                            |m

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/16703] The program breaks at the next instruction when issuing a memory breakpoint on AVR8.

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16703

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--- Comment #1 from Pedro Alves <palves at redhat dot com> ---
What does the hardware do?  Is this specific to "ATxmega256a3u", or all parts,
or a bug in the sim?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/16703] The program breaks at the next instruction when issuing a memory breakpoint on AVR8.

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16703

--- Comment #2 from Pedro Alves <palves at redhat dot com> ---
Also, what happens with regular symbol breakpoints?  E.g., "b main".

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/16703] The program breaks at the next instruction when issuing a memory breakpoint on AVR8.

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16703

--- Comment #3 from Pedro Alves <palves at redhat dot com> ---
Nevermind the last question, it's visible in the original description:

(gdb) break main
Breakpoint 1 at 0x204: file main.c, line 7.
                 ^^^^
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000206 in main () at main.c:7
       ^^^
7      PORTR.DIRSET = 3;

Good, I was scratching my head over how it could ever be different.  :-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/16703] The program breaks at the next instruction when issuing a memory breakpoint on AVR8.

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16703

--- Comment #4 from Pedro Alves <palves at redhat dot com> ---
/* Not all avr devices support the BREAK insn.  Those that don't should treat
   it as a NOP.  Thus, it should be ok.  Since the avr is currently a remote
   only target, this shouldn't be a problem (I hope).  TRoth/2003-05-14  */

static const unsigned char *
avr_breakpoint_from_pc (struct gdbarch *gdbarch,
            CORE_ADDR *pcptr, int *lenptr)
{
    static const unsigned char avr_break_insn [] = { 0x98, 0x95 };
    *lenptr = sizeof (avr_break_insn);
    return avr_break_insn;
}

So we're using the BREAK insn.

At http://www.atmel.com/images/doc0856.pdf , for BREAK, we see:

  "Program Counter: PC ← PC + 1"

So looks like that's what the hardware is supposed to do.

But then I'm very much mystified how the port has managed to work all these
years, and worry about breaking remote targets.  Could this be a case of
everyone has always been using an out of tree gdb that carries a
decr_pc_after_break patch?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From gdb-prs-return-15395-listarch-gdb-prs=sources.redhat.com@sourceware.org Fri Mar 14 10:37:33 2014
Return-Path: <gdb-prs-return-15395-listarch-gdb-prs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb-prs@sources.redhat.com
Received: (qmail 23324 invoked by alias); 14 Mar 2014 10:37:33 -0000
Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-prs.sourceware.org>
List-Subscribe: <mailto:gdb-prs-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-prs/>
List-Post: <mailto:gdb-prs@sourceware.org>
List-Help: <mailto:gdb-prs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: gdb-prs-owner@sourceware.org
Delivered-To: mailing list gdb-prs@sourceware.org
Received: (qmail 23301 invoked by uid 48); 14 Mar 2014 10:37:33 -0000
From: "palves at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug breakpoints/16703] The program breaks at the next instruction
 when issuing a memory breakpoint on AVR8.
Date: Fri, 14 Mar 2014 10:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: breakpoints
X-Bugzilla-Version: 7.7
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: palves at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: pierre.langlois at embecosm dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-16703-4717-iibXoysXaa@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-16703-4717@http.sourceware.org/bugzilla/>
References: <bug-16703-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-q1/txt/msg00403.txt.bz2
Content-length: 391

https://sourceware.org/bugzilla/show_bug.cgi?id\x16703

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gingold at adacore dot com

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/16703] The program breaks at the next instruction when issuing a memory breakpoint on AVR8.

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16703

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |avr

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/16703] The program breaks at the next instruction when issuing a memory breakpoint on AVR8.

[pierre.langlois at embecosm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16703

--- Comment #5 from Pierre Langlois <pierre.langlois at embecosm dot com> ---
Hello Pedro,

The reason why this has not been addressed is because memory breakpoint are
only supported by the simulation models. On real hardware, memory breakpoints
are not possible due to the flash memory being read-only. So I believe up until
now, only hardware breakpoints have been used.

For instance, I ran the same test using AVaRice (see the following GDB
session), and it resorts to hardware breakpoints.

AVaRice reports the following memory-map:

  Sending packet: $qXfer:memory-map:read::0,18a#b4...Ack
  Packet received: l<memory-map>\n  <memory type="ram" start="0x800000"
  length="0x20000" />\n  <memory type="flash" start="0" length="0x48400">\n
  <property name="blocksize">0x80</property>\n  </memory>\n</memory-map>\n

Resulting in this:
  Note: automatically using hardware breakpoints for read-only addresses.

----------------------------------------------------------------------------

GNU gdb (AVR 8-bit toolchain (built 20140310)) 7.7.50.20140314-cvs
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=avr".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.atmel.com>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) file atxmega-test.elf
Reading symbols from atxmega-test.elf...done.
(gdb) set debug remote 1
(gdb) target remote :4242
Remote debugging using :4242
Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack
Packet received: qXfer:memory-map:read+
Packet qSupported (supported-packets) is supported
Sending packet: $Hg0#df...Ack
Packet received:
Sending packet: $qTStatus#49...Ack
Packet received:
Packet qTStatus (trace-status) is NOT supported
Sending packet: $?#3f...Ack
Packet received: S05
Sending packet: $qfThreadInfo#bb...Ack
Packet received:
Sending packet: $qL1160000000000000000#55...Ack
Packet received:
Sending packet: $Hc-1#09...Ack
Packet received:
Sending packet: $qC#b4...Ack
Packet received:
Sending packet: $qAttached#8f...Ack
Packet received:
Packet qAttached (query-attached) is NOT supported
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $g#67...Ack
Packet received:
000000000000000000000000000000000000000000000000000000000000000000ff5f00000000
0x00000000 in __vectors ()
Sending packet: $qSymbol::#5b...Ack
Packet received:
Packet qSymbol (symbol-lookup) is NOT supported
(gdb) break main
Sending packet: $qXfer:memory-map:read::0,18a#b4...Ack
Packet received: l<memory-map>\n  <memory type="ram" start="0x800000"
length="0x20000" />\n  <memory type="flash" start="0" length="0x48400">\n
<property name="blocksize">0x80</property>\n  </memory>\n</memory-map>\n
Sending packet: $m204,2#61...Ack
Packet received: 83e0
Breakpoint 1 at 0x204: file main.c, line 7.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.
Sending packet: $Z1,204,2#ab...Ack
Packet received: OK
Packet Z1 (hardware-breakpoint) is supported
Sending packet: $vCont?#49...Ack
Packet received:
Packet vCont (verbose-resume) is NOT supported
Sending packet: $Hc0#db...Ack
Packet received:
Sending packet: $c#63...Ack
Packet received: T0520:00;21:fc5f;22:04020000;
Sending packet: $z1,204,2#cb...Ack
Packet received: OK

Breakpoint 1, main () at main.c:7
7         PORTR.DIRSET = 3;
(gdb) q
A debugging session is active.

        Inferior 1 [Remote target] will be killed.

        Quit anyway? (y or n) y

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/16703] The program breaks at the next instruction when issuing a memory breakpoint on AVR8.

[pierre.langlois at embecosm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16703

Pierre Langlois <pierre.langlois at embecosm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeremy.bennett at embecosm dot com
                   |                            |, vidarlsw at hotmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/16703] The program breaks at the next instruction when issuing a memory breakpoint on AVR8.

[palves at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16703

--- Comment #6 from Pedro Alves <palves at redhat dot com> ---
Memory map support was added in 2006-09-21, and the avr port
goes all the back back to at least 2002-04-25.  Given the flash issue, I think
that it's quite likely that older remote targets / servers just handled Z0
packets as hardware breakpoints behind the scenes, and therefore reported the
PC as the breakpoint's address.  So setting decr_pc_after_break would break
those old stubs/servers/etc.  I don't if we should care.  Assuming all probes
nowadays send a memory map, probably not.  Tristan, any comments?

-- 
You are receiving this mail because:
You are on the CC list for the bug.