From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107275 invoked by alias); 16 Jan 2018 16:18:20 -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 107259 invoked by uid 89); 16 Jan 2018 16:18:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=satisfying, H*r:sk:static., seven X-HELO: mail-wm0-f46.google.com Received: from mail-wm0-f46.google.com (HELO mail-wm0-f46.google.com) (74.125.82.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Jan 2018 16:18:18 +0000 Received: by mail-wm0-f46.google.com with SMTP id g1so9468876wmg.2 for ; Tue, 16 Jan 2018 08:18:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=jypQJGGeUtmI7c5HqI+9vnDhCDtE8oP4+xiek6gygsw=; b=Pk+/zwmW+roz/wDqY7YRRi6JdE5wKE57rUouFGjQHTc3eKIxkIhXCcU06VZn6tmtnu 9ITEuEFz1TWuFQ1GM6ypT30zaTKpEdjANwkY5vUbTB7QygyS7hcuQu2fWb2oukZ+x949 OWyxY2zYv/E0dpuTzIZb6FNoj31ifoWano3MUAM8ekU+3c0cdQcol+nJqLP8cq0O3AQe Kp38AYzaHOSDiFTshhU1oGRpAi/WvNAtNk2ldwK+m9TwrcsvowxzvS1VBioibcns1Mvt xI8BYWK9l2ap5LweFv8XN93ZhpkO1lCH/0a9oblmlzdkIAncfLfl1gy5vr9UAOE/T1NM RO4g== X-Gm-Message-State: AKwxytf3ZHJa5JymqaEDD5DNf70y6xNaCOv72A7H8Qi4EQfz4zQ95Nq3 84TsYb9fE0vQwiNDzC+Wqk8Mgw== X-Google-Smtp-Source: ACJfBovCvgMeetxMeONlsUHSpsnLyINzzT5TRzghCryWB6idSomr2nlAWXdQUi0PZqB9P1pEQw1r2Q== X-Received: by 10.28.169.200 with SMTP id s191mr6463366wme.9.1516119496240; Tue, 16 Jan 2018 08:18:16 -0800 (PST) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id s105sm3920017wrc.89.2018.01.16.08.18.15 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 16 Jan 2018 08:18:15 -0800 (PST) From: Yao Qi To: gdb-patches@sourceware.org Subject: Re: [RFC 00/15] Remove regcache::m_readonly_p References: <1512125286-29788-1-git-send-email-yao.qi@linaro.org> Date: Tue, 16 Jan 2018 16:18:00 -0000 In-Reply-To: <1512125286-29788-1-git-send-email-yao.qi@linaro.org> (Yao Qi's message of "Fri, 1 Dec 2017 10:47:51 +0000") Message-ID: <86fu75g4l5.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: 2018-01/txt/msg00303.txt.bz2 Yao Qi writes: > regcache is used in many places in gdb in different ways, so regcache > becomes a flat and fat object. That exposes some unnecessary APIs to > different part, and some APIs are misused or abused: > > 1) gdbarch methods pseudo_register_read and pseudo_register_read_value > have a parameter 'regcache *', but these two gdbarch methods only need > raw_read* and cooked_read* methods. So it is better to pass a class > which only has raw_read* and cooked_read* methods, and other regcache > methods are invisible to each gdbarch implementation. > > 2) target_ops methods to_fetch_registers and to_store_registers have a > parameter 'regcache *', but these two target_ops methods only need > raw_supply and raw_collect methods, because raw registers are from target > layer, pseudo registers are "composed" or "created" by gdbarch. > > 3) jit.c uses regcache in an odd way, and record-full.c should use > a simple version regcache instead of an array (see patch 11) > > Beside these api issues, one issue in regcache is that there is no > type or class for readonly regcache. We use a flag field m_readonly_p > to indicate the regcache is readonly or not, so some regcache apis have > assert that this regcache is or is not readonly. The better way to do > this is to create a new class for readonly regcache which doesn't have > write methods at all. > > This patch series fixes all of the problems above except 2) (I had a > patch to fix 2 in my tree, but still need more time to polish it.) by > designing a class hierarchy about regcache, like this, > > reg_buffer > ^ > | > ------+----- > ^ > | > regcache_read > ^ > | > ------+------ > ^ ^ > | | > reg_buffer_rw regcache_readonly > ^ > | > regcache > > Class reg_buffer is a simple class, having register contents and status > (in patch 7). regcache_read is an abstract class only having raw_read* > and cooked_read* methods (in patch 8). reg_buffer_rw is a class which > has read and write methods, but it disconnects from target, IOW, the > write doesn't go through. Class regcache_readonly is the readonly > regcache, created from regcache::save method. > > This patch series is tested on {x86_64, aarch64, ppc64}-linux. It is > an RFC, want to get comments. I write them in at least seven different > ways, and this one is satisfying. I don't push them in until 8.1 is > branched. Ping. I'd like to know what do you think of this design, patches 7/15 to 15/15. --=20 Yao (=E9=BD=90=E5=B0=A7)