From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:41628)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <serge.fdrv@gmail.com>) id 1Zcz9T-0002go-Hy
	for qemu-devel@nongnu.org; Fri, 18 Sep 2015 13:08:48 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <serge.fdrv@gmail.com>) id 1Zcz9Q-0008SS-8e
	for qemu-devel@nongnu.org; Fri, 18 Sep 2015 13:08:47 -0400
Received: from mail-lb0-x22b.google.com ([2a00:1450:4010:c04::22b]:33562)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <serge.fdrv@gmail.com>) id 1Zcz9Q-0008SL-09
	for qemu-devel@nongnu.org; Fri, 18 Sep 2015 13:08:44 -0400
Received: by lbbvu2 with SMTP id vu2so28332179lbb.0
	for <qemu-devel@nongnu.org>; Fri, 18 Sep 2015 10:08:43 -0700 (PDT)
References: <1442552129-19242-1-git-send-email-rth@twiddle.net>
	<1442552129-19242-5-git-send-email-rth@twiddle.net>
	<CAFEAcA9aqH2g6M8KO5kM+eO-RQ-sY9NAkj+7QN2SZBamYQHM2Q@mail.gmail.com>
	<55FC3060.3010304@twiddle.net>
From: Sergey Fedorov <serge.fdrv@gmail.com>
Message-ID: <55FC4518.6010207@gmail.com>
Date: Fri, 18 Sep 2015 20:08:40 +0300
MIME-Version: 1.0
In-Reply-To: <55FC3060.3010304@twiddle.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v2 04/22] target-*: Introduce and use
 cpu_breakpoint_test
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Richard Henderson <rth@twiddle.net>, Peter Maydell <peter.maydell@linaro.org>
Cc: =?UTF-8?Q?Alex_Benn=c3=a9e?= <alex.bennee@linaro.org>, QEMU Developers <qemu-devel@nongnu.org>, Aurelien Jarno <aurelien@aurel32.net>

On 18.09.2015 18:40, Richard Henderson wrote:
> On 09/18/2015 03:32 AM, Peter Maydell wrote:
>>> +        if (unlikely(cpu_breakpoint_test(cs, dc->pc, BP_ANY))) {
>>> +            gen_exception_internal_insn(dc, 0, EXCP_DEBUG);
>>> +            /* Advance PC so that clearing the breakpoint will
>>> +               invalidate this TB.  */
>>> +            dc->pc += 2;
>>> +            goto done_generating;
>>> +        }
>>>          if (num_insns == max_insns && (tb->cflags & CF_LAST_IO)) {
>>>              gen_io_start();
>>>          }
>> Do you know why some but not all targets do this "advance PC"
>> thing if there's a breakpoint?
> No.  I don't believe I've seen it before yesterday.
>
> My suspicion is that if we have a TB that would span two pages, and the
> breakpoint is exactly at the page boundary, then we must advance the pc like
> this so that it's clear that the TB utilizes the second page.
>
> If so, it means that there are some targets that are broken based on this (e.g.
> i386), and there are a few for which this situation is impossible, and this
> fixup is cargo culting (e.g. aarch64).
>

I noticed that this fixup is only used combined with thing like "goto
done_generating". Other targets terminate the loop only after translated
the insn, e.g. with "dc->is_jmp = DISAS_JUMP".

Best regards,
Sergey