From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54638) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoDrk-0000ip-85 for qemu-devel@nongnu.org; Mon, 19 Oct 2015 13:04:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZoDrf-0002VD-6R for qemu-devel@nongnu.org; Mon, 19 Oct 2015 13:04:56 -0400 Received: from mail-qg0-x236.google.com ([2607:f8b0:400d:c04::236]:34005) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZoDrf-0002V6-27 for qemu-devel@nongnu.org; Mon, 19 Oct 2015 13:04:51 -0400 Received: by qgem9 with SMTP id m9so14477004qge.1 for ; Mon, 19 Oct 2015 10:04:50 -0700 (PDT) Sender: Richard Henderson 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> From: Richard Henderson Message-ID: <562522AD.4050101@twiddle.net> Date: Mon, 19 Oct 2015 07:04:45 -1000 MIME-Version: 1.0 In-Reply-To: <5624CE3A.3000505@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed 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: Sergey Fedorov , Peter Maydell Cc: QEMU Developers 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? r~