From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3170 invoked by alias); 5 Dec 2013 14:37:37 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 3159 invoked by uid 89); 5 Dec 2013 14:37:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Dec 2013 14:37:35 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rB5EbR0i013932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Dec 2013 09:37:27 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rB5EbOkP026264; Thu, 5 Dec 2013 09:37:25 -0500 Message-ID: <52A08FA4.9000002@redhat.com> Date: Thu, 05 Dec 2013 14:37:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yao Qi CC: Pedro Alves , Mark Kettenis , gdb-patches@sourceware.org Subject: Re: [PATCH 2/3] skip_prolgoue (amd64) References: <1385735051-27558-1-git-send-email-yao@codesourcery.com> <1385735051-27558-3-git-send-email-yao@codesourcery.com> <201311291436.rATEaZ5Z030292@glazunov.sibelius.xs4all.nl> <201311291605.rATG5XVb030184@glazunov.sibelius.xs4all.nl> <52994E79.4000004@codesourcery.com> <5299B9D0.2020304@redhat.com> <529C37A2.9000207@codesourcery.com> <529E9462.9010001@codesourcery.com> <529F1B1F.2040606@redhat.com> <529FD4B9.10008@codesourcery.com> <52A06AC1.1030209@redhat.com> <52A0888B.5000309@codesourcery.com> In-Reply-To: <52A0888B.5000309@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-12/txt/msg00183.txt.bz2 On 12/05/2013 02:07 PM, Yao Qi wrote: > On 12/05/2013 08:00 PM, Pedro Alves wrote: >> I think we can. My view here is that handling an event >> is a quick and short lived operation. GDB bursts a few reads >> in sequence, and then moves on to the next event. In that >> scenario, you get as much stale results with or without a cache. > > I disagree. Results may be staled with cache, but results may be > different, not staled, without cache. They are different because they > are red on different times, but all of them are valid. It is a snapshot > of a piece of memory on a certain moment. Sigh, I don't know why I wrote "stale" there. I meant "wrong, inconsistent, useless, whatnot". As in, if a thread changes memory while GDB is reading it, you can get incoherent/self-inconsistent results. E.g,. even if between the inferior's threads, writes to 'struct { int a, int b} ab;' are coordinated, say, with a mutex, when printing 'ab', GDB can end up reading a chunk of the structure's contents before the write, and another chunk after the write, and present that frankenstein value to the user. You can get such undefined results with or without a cache, because the "certain moment" will be different for each of the partial reads. Even each partial read is not guaranteed to be atomic. >> IOW, even without the cache, running threads can change memory as >> GDB reads it, and so the chances of hitting stale data with or >> without a cache are practically the same. OTOH, distinct target >> events (and commands, etc.) can trigger quite apart (time-wise), >> and that break the odd balance -- not flushing the cache >> between events increases the changes of hitting stale data, > > I suspect you meant "chances" instead of "changes". Yes. > >> compared to not having a cache. > > Flushing the cache decreases likelihood of getting staled data, but > can't completely remove it. Right. The trick IMO, is selecting flush points that make it so that that chances of getting an incoherent value/memory chunk are practically the same with or without a cache. Places where GDB needs to be sure to get a coherent, instantaneous snapshot view of memory need to handle that specially (we do that nowhere presently), e.g., by pausing all (affected) threads, or perhaps even something else smarter (say, with kernel help, the debugger declares intention of reading a memory range, and the kernel makes sure the associated pages don't change from the debugger's view, COW pages if some inferior threads wants to change them while the debugger is accessing them). > I am fine to use cache in non-stop mode, as > it helps performance, so we have to compromise. Right. >>>> Beside the predicate "is any thread running", another is "no thread is >>>> resumed since last flushing". Cache should be flushed when either is >>>> true. >> Not sure I understood that. > > I meant, even "none of threads is running now", we may have to flush > cache if "they were resumed" (and all stopped now). OK, I see what you mean. I was assuming "all stopped now" means "we've seen all threads report stops", but there are indeed other ways to implement that predicate, and indeed that case needs to be considered. -- Pedro Alves