From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:38652)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1a7XHW-0000RY-79
	for qemu-devel@nongnu.org; Fri, 11 Dec 2015 18:39:22 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <rth7680@gmail.com>) id 1a7XHV-0003yW-Dw
	for qemu-devel@nongnu.org; Fri, 11 Dec 2015 18:39:22 -0500
Sender: Richard Henderson <rth7680@gmail.com>
References: <1449773244-17078-1-git-send-email-serge.fdrv@gmail.com>
From: Richard Henderson <rth@twiddle.net>
Message-ID: <566B5E9E.8040108@twiddle.net>
Date: Fri, 11 Dec 2015 15:39:10 -0800
MIME-Version: 1.0
In-Reply-To: <1449773244-17078-1-git-send-email-serge.fdrv@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] target-*: Get rid of "PC advancement" trick
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: Sergey Fedorov <serge.fdrv@gmail.com>, qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>, Eduardo Habkost <ehabkost@redhat.com>, Anthony Green <green@moxielogic.com>, Alexander Graf <agraf@suse.de>, Max Filippov <jcmvbkbc@gmail.com>, Michael Walle <michael@walle.cc>, qemu-arm@nongnu.org, qemu-ppc@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>, "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, Guan Xuetao <gxt@mprc.pku.edu.cn>, Leon Alrae <leon.alrae@imgtec.com>, Aurelien Jarno <aurelien@aurel32.net>, Jia Liu <proljc@gmail.com>

On 12/10/2015 10:47 AM, Sergey Fedorov wrote:
> The "PC advancement" trick was used just after recognizing that a
> breakpoint exception was going to be generated. This trick has had two
> points:
>   1. Guarantee that tb->size isn't zero: there are many places where it's
>      expected to be non-zero. In fact, that is even stated in the comment
>      for this field.
>   2. Try to satisfy disassembler's check for instruction length. To this
>      end, PC advancement was done for estimated instruction length, but
>      actually, didn't work properly in variable-instruction-length cases.
>
> Substitute this trick with checking for TB size at the end of
> translation. If we get an empty TB then just set tb->size to 1 and skip
> disassembling. Setting tb->size to 1 is enough to get correct behaviour,
> whereas an empty TB doesn't obviously need to be disassembled.

This doesn't help when the TB already has instructions, the TB would ordinarily 
cross a page boundary, and the breakpoint is at the page boundary.


r~