From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49323 invoked by alias); 3 Apr 2017 13:58:46 -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 49304 invoked by uid 89); 3 Apr 2017 13:58:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:209.85.128.194, Hx-languages-length:2652, H*RU:209.85.128.194 X-HELO: mail-wr0-f194.google.com Received: from mail-wr0-f194.google.com (HELO mail-wr0-f194.google.com) (209.85.128.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 03 Apr 2017 13:58:44 +0000 Received: by mail-wr0-f194.google.com with SMTP id u18so33837930wrc.0 for ; Mon, 03 Apr 2017 06:58:45 -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=qUIqop/u3Nl3rSoz/iP5htD1vroZ+OcHsd0kBxPIfHM=; b=TBSrQS7azlA6L1Cv8mAKc0d5WiOdd0uVSJqDcKlnd7cKpU2+yBZMWwxiRRPIJvqD/V BiHhpS6G+gNbHVsZkqCiZUCn8yPUfOCqvEy7JhRBo3l/9jrPEXAt0tXL84jlr19cbhY8 v1zr9/ZesEn9YOloL69ujg/R/gUHqON26EuZk6i1sKQtIYYTIWBvPZgOvo0UihOf7qQK 8c43U7h7HTls7eU1XHhL4as+YrzZTM7fO2HG1BVxybcPJP83z0D+YI7DZBCF/IaGxdvR iLt2m6KVMwuDW7lDQ33UO6cCCyYiOTS9CnfNghRGCZPP3fsvuAlknW0BxMtKupLdxJvG sc3A== X-Gm-Message-State: AFeK/H3DIzZA2Aa7LWXZW/89TXT8CKqqT3+P9izh4wRg5fC2CGAHp9j4sL93/e5VRD5A7Q== X-Received: by 10.28.168.150 with SMTP id r144mr10139695wme.43.1491227923055; Mon, 03 Apr 2017 06:58:43 -0700 (PDT) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id g10sm9753001wrb.56.2017.04.03.06.58.41 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 03 Apr 2017 06:58:42 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: Alan Hayward , "gdb-patches\@sourceware.org" , Subject: Re: extract_unsigned_integer API (Re: [PATCH] Remove MAX_REGISTER_SIZE from frame.c) References: <86lgspqisk.fsf@gmail.com> <5f2f0cb0-6265-46aa-4ad6-eda5ba817da4@redhat.com> <8660itnzvv.fsf@gmail.com> <93774758-0354-c67b-9733-005b3d56fbfa@redhat.com> <2427e9d3-4d91-7d63-a8e4-36aeb233b86e@redhat.com> Date: Mon, 03 Apr 2017 13:58:00 -0000 In-Reply-To: <2427e9d3-4d91-7d63-a8e4-36aeb233b86e@redhat.com> (Pedro Alves's message of "Tue, 28 Mar 2017 23:23:24 +0100") Message-ID: <86d1ctlhin.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-04/txt/msg00002.txt.bz2 Pedro Alves writes: > Thinking about this a bit more, if we went this direction, I think the > simplest would be to add an extract::size() method that returned the > size of the buffer, and use that for bounds when filling in the > data, like: > > extractor extr; > frame_unwind_register (frame, regnum, ext.buffer (), ext.size ()); > return extr.extract (type_len, byte_order); > > If type_len is larger than the buffer size, then we'll still get an > error either inside extractor::extract, and maybe earlier > inside frame_unwind_register (if it had that size parameter). Yes, that is the simplest way. > > Though for the particular case of frame_unwind_register, since the > frame machinery works with struct value's, inside frame_unwind_register > there's going to be a value created already, and that has a contents > buffer we could access directly. So e.g., > inside frame_unwind_register_signed, we should be able to use > frame_unwind_register_value directly thus avoid the need for the local > buffer and copying data. How is the patch below? --=20 Yao (=E9=BD=90=E5=B0=A7) =46rom d8f91babfcd6810ff4942aa8275d3d447ae1a83a Mon Sep 17 00:00:00 2001 From: Yao Qi Date: Wed, 29 Mar 2017 16:49:11 +0100 Subject: [PATCH] Use frame_unwind_register_value in frame_unwind_register_unsigned gdb: 2017-03-29 Yao Qi * frame.c (frame_unwind_register_unsigned): Call frame_unwind_register_value. --- gdb/frame.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/gdb/frame.c b/gdb/frame.c index d98003d..a10f3e5 100644 --- a/gdb/frame.c +++ b/gdb/frame.c @@ -1270,10 +1270,27 @@ frame_unwind_register_unsigned (struct frame_info *= frame, int regnum) struct gdbarch *gdbarch =3D frame_unwind_arch (frame); enum bfd_endian byte_order =3D gdbarch_byte_order (gdbarch); int size =3D register_size (gdbarch, regnum); - gdb_byte buf[MAX_REGISTER_SIZE]; + struct value *value =3D frame_unwind_register_value (frame, regnum); =20 - frame_unwind_register (frame, regnum, buf); - return extract_unsigned_integer (buf, size, byte_order); + gdb_assert (value !=3D NULL); + + if (value_optimized_out (value)) + { + throw_error (OPTIMIZED_OUT_ERROR, + _("Register %d was not saved"), regnum); + } + if (!value_entirely_available (value)) + { + throw_error (NOT_AVAILABLE_ERROR, + _("Register %d is not available"), regnum); + } + + ULONGEST r =3D extract_unsigned_integer (value_contents_all (value), siz= e, + byte_order); + + release_value (value); + value_free (value); + return r; } =20 ULONGEST --=20 1.9.1