From patchwork Mon Apr 10 08:59:44 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 19933 Received: (qmail 26733 invoked by alias); 10 Apr 2017 08:59:52 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 26693 invoked by uid 89); 10 Apr 2017 08:59:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=disappeared, month, brand X-HELO: mail-wm0-f49.google.com Received: from mail-wm0-f49.google.com (HELO mail-wm0-f49.google.com) (74.125.82.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Apr 2017 08:59:49 +0000 Received: by mail-wm0-f49.google.com with SMTP id w64so33228412wma.0 for ; Mon, 10 Apr 2017 01:59:50 -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=hfNhpmwHTGfJQe31MieF604LmpooMlQQqT24EFk3E/4=; b=FZSG5ZebmyRW8ZW5ZKw/FwR0w+UuHHjacWJvmF6rmjQLxQOVCFiL95nR3I0FJv1SUc xaOP+yNyLgwOYOnlg1tPZr2pUAxZ3VCGWY72iI6HcuanQkDdN4MvGq1AAzfnid+Z04Zp MTert1tlA5sch3sjCrr8eJT72IpFZC8k5MTMmUPjfEAI73CI+XNS1hr3Zqqszy1n/kYH zn1mr5qOM6StUUUiikFubTPEMmwrNwX+BvVHGTixgguYQ8H4m4cKbBK5oa3i6hkzUlMl 51LoeXwN3msQLQfWdECxuDJy1pgI9iiEnsICKIZt0HQcY4rL3jo/v27LgUTTpBmeRRo2 7/3w== X-Gm-Message-State: AN3rC/6vQf5qvfJxJ3zZOZ9fBQSJuww/VghfsAEtN9wE3/RX9AjU/3P2y1SH+n9LiUW8wg== X-Received: by 10.28.197.12 with SMTP id v12mr8290912wmf.82.1491814788684; Mon, 10 Apr 2017 01:59:48 -0700 (PDT) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id k13sm9397472wmi.28.2017.04.10.01.59.47 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 10 Apr 2017 01:59:48 -0700 (PDT) From: Yao Qi To: Alan Hayward Cc: "gdb-patches\@sourceware.org" , Subject: Re: [PATCH] Remove MAX_REGISTER_SIZE from regcache.c References: <562B2F6F-F3C6-4A76-9489-57539F396C94@arm.com> <868tnvukjh.fsf@gmail.com> <7359B5C0-BF61-42E2-9886-B322C1825865@arm.com> <0DADF920-69B9-4F96-A153-6965E56B5DA8@arm.com> <868tneq1xj.fsf@gmail.com> Date: Mon, 10 Apr 2017 09:59:44 +0100 In-Reply-To: (Alan Hayward's message of "Wed, 5 Apr 2017 18:10:09 +0000") Message-ID: <86efx0ljsv.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-IsSubscribed: yes Alan Hayward writes: >>> @@ -395,9 +404,9 @@ regcache_restore (struct regcache *dst, >>> { >>> enum register_status status; >> >> Can we move "buf" here? and initialize it with the register_size, >> >> std::vector buf (register_size (gdbarch, regnum)); >> >> then, we don't need max_register_size (). >> > > Problem with this is that we are then creating a brand new buffer for each > iteration of the loop, which is a little heavyweight. > We could create an empty buf outside the loop and re-size it each iteration, > but that's still going to cost. > How is this patch below? I class-fied regcache last month in my local tree, and MAX_REGISTER_SIZE is disappeared from regcache.c. I suggested using std::vector in a loop so that it is easy to rebase my patches. diff --git a/gdb/regcache.c b/gdb/regcache.c index 37bc2f0..41c23a5 100644 --- a/gdb/regcache.c +++ b/gdb/regcache.c @@ -374,17 +374,15 @@ regcache_save (struct regcache *dst, regcache_cooked_read_ftype *cooked_read, } static void -regcache_restore (struct regcache *dst, - regcache_cooked_read_ftype *cooked_read, - void *cooked_read_context) +regcache_restore (struct regcache *dst, struct regcache *src) { struct gdbarch *gdbarch = dst->descr->gdbarch; - gdb_byte buf[MAX_REGISTER_SIZE]; int regnum; /* The dst had better not be read-only. If it is, the `restore' doesn't make much sense. */ gdb_assert (!dst->readonly_p); + gdb_assert (src->readonly_p); /* Copy over any registers, being careful to only restore those that were both saved and need to be restored. The full [0 .. gdbarch_num_regs + gdbarch_num_pseudo_regs) range is checked since some architectures need @@ -393,11 +391,8 @@ regcache_restore (struct regcache *dst, { if (gdbarch_register_reggroup_p (gdbarch, regnum, restore_reggroup)) { - enum register_status status; - - status = cooked_read (cooked_read_context, regnum, buf); - if (status == REG_VALID) - regcache_cooked_write (dst, regnum, buf); + if (src->register_status[regnum] == REG_VALID) + regcache_cooked_write (dst, regnum, register_buffer (src, regnum)); } } } @@ -424,7 +419,7 @@ regcache_cpy (struct regcache *dst, struct regcache *src) if (!src->readonly_p) regcache_save (dst, do_cooked_read, src); else if (!dst->readonly_p) - regcache_restore (dst, do_cooked_read, src); + regcache_restore (dst, src); else regcache_cpy_no_passthrough (dst, src); }