From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118035 invoked by alias); 23 Aug 2017 10:03:10 -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 118007 invoked by uid 89); 23 Aug 2017 10:03:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=cooked, H*r:sk:static. X-HELO: mail-it0-f54.google.com Received: from mail-it0-f54.google.com (HELO mail-it0-f54.google.com) (209.85.214.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Aug 2017 10:03:03 +0000 Received: by mail-it0-f54.google.com with SMTP id 190so4503815itx.0 for ; Wed, 23 Aug 2017 03:03:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=m9zZKY18Filn66XHsCWN2L0irIJGYw6yW/aPp3Vo7HA=; b=LU0Rl9xLFF9h+HUVKDp/bBhZyTCwgkYvf6vhvZPi3fq2NQ432BePWo5EsIhvzKBhBF Au2bvFPrGZwXAX+WYsCJA1iZSiGwHJZ6cCpWsMnssGV9mAvSAy9yMy8TJ1W8adyP88TI Fxk/gryiuU6Y7mVnYzpkothE9b8rOco3I4AVRNIWcsXuNpsRBWAaeGPIMqO1kZ9DXXVA /YedJ+7rtSEAI249r9Sp0kF4WUBeynz57rAPR35sFCeWltFIhnwyvb/bA8sJmnoH/YoM sp7Gko5kcitQ/Tgzh6dDCja87cfPm4BgM6DhAPA5BurwPTZ4JrfTyDTVYicqrDswAreG oPMA== X-Gm-Message-State: AHYfb5jKF3djqTVlE9ZddHJttU7SqpLRZIsJnyspdmzsnOmfTZYQP7Vn RW5We+R/nRXEKw== X-Received: by 10.36.44.130 with SMTP id i124mr2240366iti.39.1503482581443; Wed, 23 Aug 2017 03:03:01 -0700 (PDT) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id n67sm779165itg.39.2017.08.23.03.03.00 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 23 Aug 2017 03:03:01 -0700 (PDT) From: Yao Qi To: Alan Hayward Cc: "gdb-patches\@sourceware.org" , nd Subject: Re: [PATCH 0/7] Regcache: Split out target regcache functionality References: Date: Wed, 23 Aug 2017 10:03:00 -0000 In-Reply-To: (Alan Hayward's message of "Thu, 17 Aug 2017 08:46:29 +0000") Message-ID: <86valer48e.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00435.txt.bz2 Alan Hayward writes: > A target_regcache is a regcache connected to a target. Reads and > writes of register values are passed through to the target. > A target_regcache cannot be readonly (because this doesn't make > sense). At this stage, can we don't assume the readonly-ness of target_regcache? https://sourceware.org/ml/gdb-patches/2017-07/msg00252.html > > Meanwhile, a regcache (sometime referred to as a detached regcache) > is not connected to a target. By default it is readonly, but does > not have to be. In addition to the raw registers a regcache also > caches cooked register values. Duplicating a target_regcache will > always result in a detached regcache. > > Both regcache and target_regcache support the full set of raw_read, > raw_write, raw_collect, raw_supply, cooked_read, cooked_write > functions and all their variations. A user of a regache does not > need to treat the two types any differently - your regcache just > does the correct thing. For example, on a target_regcache, > raw_write will write to both the cache and the target, but on > a recache it will only write to the cache. > > With this set of patches, the regcache for the current thread (as > given by get_current_regcache()), is now a target_regcache, that > will perform exactly the same functionality as the regcache in > the exisiting head. > > An earlier plan for this set of patches was that the detached > regcache would not support raw_write, raw_collect, cooked_read, > cooked_write. The problem is many of the target hooks then need My suggestion was that detached regcache doesn't have {raw,cooked}_{read,write}_ methods, only has collect and supply methods. and attached one has {raw,cooked}_{read,write}_ methods. https://sourceware.org/ml/gdb-patches/2017-07/msg00127.html > updating to only accept target_regcache. Many of the implementations > of the target hooks then call back into the regcache, causing those > functions in turn to be dependant on the new classes, exploding the > size of the patch. It then become very fiddly/confusing to maintain > which type of regcache is required at any point. target hooks should call regcache supply and collect methods, IMO. --=20 Yao (=E9=BD=90=E5=B0=A7)