From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5896 invoked by alias); 5 Dec 2013 11:47:51 -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 5883 invoked by uid 89); 5 Dec 2013 11:47:50 -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 11:47:49 +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 rB5Bleia012621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Dec 2013 06:47:40 -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 rB5Blc6j031314; Thu, 5 Dec 2013 06:47:39 -0500 Message-ID: <52A067DA.7060304@redhat.com> Date: Thu, 05 Dec 2013 11:47: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: Doug Evans CC: Yao Qi , Mark Kettenis , gdb-patches 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-12/txt/msg00177.txt.bz2 On 12/04/2013 05:54 PM, Doug Evans wrote: > > The dcache and non-stop are basically incompatible, but we need both. > With any other thread still running the ground can be pulled out from > underneath my view of memory from a stopped thread (even when I'm in > the middle of viewing it - I can imagine a pretty-printer of a complex > object getting really confused for example). Right. My view is that for a single quick operation, it's fine to rely on the cache. E.g., a backtrace, or printing a variable while other threads are running. GDB can give you skewed results here with or without the cache. Between single higher level operations though, a lot of time could pass between two backtraces, and the likeliness of the cache getting stale increases. This suggests investigating the idea of having the cache have a time based lifetime, in addition. Though I suspect that's a lot of more complexity, for diminishing returns. It's nice that the second backtrace is faster than the first, but it's really time of the first backtrace that we should be optimizing for, IMO. > It feels like there's diminishing returns and increasing costs the > farther we go to try to protect the user from this. Exactly. Related, I've considered before that some memory accesses may need to be atomic with the inferior (e.g., things like reading dynamic linker structures), and that GDB core will need to know to stop the target, batch a few reads, and re-resume the target. And that that could also be extended to a user knob -- "set want-to-be-sure-values-I'm-reading-aren't-skewed-by-running-threads-so-please-pause-them-for-me-as-needed on/off". Possibly with a shorter spelling. :-) -- Pedro Alves