From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoECr-0006Kg-0C for qemu-devel@nongnu.org; Mon, 19 Oct 2015 13:26:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZoECn-00016r-N3 for qemu-devel@nongnu.org; Mon, 19 Oct 2015 13:26:44 -0400 Received: from mail-lf0-x22e.google.com ([2a00:1450:4010:c07::22e]:33465) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoECn-000164-FR for qemu-devel@nongnu.org; Mon, 19 Oct 2015 13:26:41 -0400 Received: by lffv3 with SMTP id v3so115821612lff.0 for ; Mon, 19 Oct 2015 10:26:40 -0700 (PDT) References: <1444774253-10492-1-git-send-email-rth@twiddle.net> <561EC2FA.40901@twiddle.net> <56204F63.6010501@twiddle.net> <562104CB.1080801@gmail.com> <5624214B.3020401@twiddle.net> <5624CE3A.3000505@gmail.com> <562522AD.4050101@twiddle.net> From: Sergey Fedorov Message-ID: <562527CE.2040906@gmail.com> Date: Mon, 19 Oct 2015 20:26:38 +0300 MIME-Version: 1.0 In-Reply-To: <562522AD.4050101@twiddle.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] target-*: Advance pc after recognizing a breakpoint List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , Peter Maydell Cc: QEMU Developers On 19.10.2015 20:04, Richard Henderson wrote: > On 10/19/2015 01:04 AM, Sergey Fedorov wrote: >> On 19.10.2015 01:46, Richard Henderson wrote: >>> On 10/16/2015 04:08 AM, Sergey Fedorov wrote: >>>> On 16.10.2015 04:14, Richard Henderson wrote: >>>>> On 10/16/2015 03:36 AM, Peter Maydell wrote: >>>>>> On 14 October 2015 at 22:02, Richard Henderson >>>>>> wrote: >>>>>>> On 10/15/2015 06:34 AM, Peter Maydell wrote: >>>>>>>> >>>>>>>> This is still the same cryptic comment we have in the >>>>>>>> targets which do do this. Can we have something >>>>>>>> that is a bit more explanatory about what is going on and >>>>>>>> why we need to do this, please? >>>>>>> >>>>>>> >>>>>>> Suggestions? >>>>>> >>>>>> ...well, I don't entirely understand the problem it's >>>>>> fixing, which is why I'm asking for a better comment :-) >>>>> >>>>> Heh. Fair enough. How about >>>>> >>>>> /* The address covered by the breakpoint must be included in >>>>> [tb->pc, tb->pc + tb->size) in order to for it to be >>>>> properly cleared -- thus we increment the PC here so that >>>>> the logic setting tb->size below does the right thing. */ >>>>> >>>>> There are two edge cases that cause the problem with clearing that >>>>> could be described, but I think that the comment becomes too >>>>> bulky, as >>>>> well as confuses the situation for someone cutting-and-pasting the >>>>> logic to a new port. >>>> >>>> Maybe we could rather fix that condition in >>>> tb_invalidate_phys_page_range()? It seems weird that it can't handle a >>>> zero-sized TB. >>> >>> We also need to be able to handle a TB which crosses a page. E.g. the >>> breakpoint is at the page boundary, and we fall through into it from >>> the top. This will be true on e.g. x86. This is not simply true for >>> breakpoint insertion/removal, but also page invalidation. >>> >>> The same fix, adding a byte to the size, handles this as well. >> >> It's clear except that instructions crossing a page boundary can be >> different in size. AFAIK, x86 instructions can be up to 15-byte long. >> What if only the very last byte of instruction crosses a page boundary? > > Then only the last byte crosses? What's your point? My point is if "adding a byte to the size" handles such case as well. Best, Sergey