From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82544 invoked by alias); 23 May 2017 18:30:52 -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 82533 invoked by uid 89); 23 May 2017 18:30:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f51.google.com Received: from mail-wm0-f51.google.com (HELO mail-wm0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 May 2017 18:30:50 +0000 Received: by mail-wm0-f51.google.com with SMTP id d127so37424479wmf.0 for ; Tue, 23 May 2017 11:30:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=uNWR8mZ4jiBjSftjZASjIpMRh7bMMn3AZ8fjg9ju11o=; b=OYAe7V+WT36PRguNVAarYkoIhwZo+N3ZM3D80t5oIfxWkXVJHW4iRDKGJKHM+15MwO 1WmPH9NCFAvYA6SUe0Z1KQOGO5VVhw3MpHkLuFnWSXn6XCCITFqz0HK5kwEmGT8R+XsP 5tiUbVAyY1EJkfzIastU6ALBySfsrRrkYg4mMr31zQ1k1QqTmcVUFYlYL2SbeBo7QxZ5 lQe/KNrTGEP67XBJK7qnB1HGjC1UhE5dOlAYO9uOzL/4z+XzFqNKPrELvBr9web7+fo7 l9+dRormC+JFZOLyJYsmqlKA0PyyI2tnP9+INx3dmGHdA5dkU+PmMiEVmqrzfqqNGg0Z 9pfw== X-Gm-Message-State: AODbwcCpXQcO4Gey0+B7koCTRC15NTT4vLxJm2l0nnYC1xE3ogVoRehJ fxAxCICd++NhOrvd X-Received: by 10.28.9.204 with SMTP id 195mr3195510wmj.97.1495564251780; Tue, 23 May 2017 11:30:51 -0700 (PDT) Received: from [192.168.43.236] ([89.214.53.176]) by smtp.gmail.com with ESMTPSA id y190sm2181818wmy.15.2017.05.23.11.30.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 11:30:50 -0700 (PDT) Subject: Re: [PATCH 3/11] Add MIPS_MAX_REGISTER_SIZE (2/4) To: Alan Hayward References: <3C00280E-37C9-4C0A-9DA6-F3B9DB1A6E8F@arm.com> <86y3v7uf9j.fsf@gmail.com> <806B436F-EFA1-4200-AC54-9036D166C9B9@arm.com> <867f1m8nhm.fsf@gmail.com> <8637bx9jsw.fsf@gmail.com> <78A7E8EA-7203-44DF-B7FD-63E75A5ECEF5@arm.com> <540372d8-efc3-f842-5cac-cd813bacc3f5@redhat.com> <4F90CD36-759D-4BDA-BFEC-8DD86F44A0B7@arm.com> Cc: Yao Qi , "gdb-patches@sourceware.org" , nd From: Pedro Alves Message-ID: Date: Tue, 23 May 2017 18:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <4F90CD36-759D-4BDA-BFEC-8DD86F44A0B7@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00511.txt.bz2 On 05/23/2017 06:49 PM, Alan Hayward wrote: > >> On 22 May 2017, at 18:15, Pedro Alves wrote: >> I wonder whether we can get rid of the LONGEST / host integer >> middleman and simplify things while at it. For instance, what if we >> had a version of raw_collect that took the destination buffer length >> as parameter: >> >> regcache->raw_collect_integer (regnum, (gdb_byte *) addr, len); >> >> that would copy bytes over into addr, and if the register is >> narrower than LEN, then it'd insert the necessary >> leading zeros (or 0xFFs if signed extension necessary), >> and if the registers is wider than LEN, then it'd skip >> copying enough significant bytes so that LEN fits. >> >> Likewise for regcache->raw_supply. > > Is it the case that gdb always does a store_integer after a raw_collect > of a (U)LONGEST? > And always an extract_integer before a raw_supply of a (U)LONGEST ? > (Both of these are tricky to grep for, because the code sequence is over > multiple lines) The observation here is that we're transferring integer data between two places that seemingly both use target formatting: target integer 1 -> host integer -> target integer 2 when the target integer 1 and 2 have the same sizes, then we copy data directly without the host integer middle man. But when they don't have the same size, we do the host integer conversion steps. I was questioning having that step in the first place. If the target integers have different sizes, we'll either end up with zero/sign extension, or truncation. It seems to me offhand that doing those directly in the destination buffer shouldn't be difficult? > > I was going to mock up a new raw_collect_integer, but then got carried > away and wrote the full patch changes. > This version makes the MIPS files look neater. Hmm, I think you may have misunderstood. The main point was to avoid having to have T/LONGEST temporary at all here: > +template > +typename std::enable_if<(std::is_same::value > + || std::is_same::value), > + void>::type > +regcache::raw_supply_integer (int regnum, const gdb_byte *addr, int addr_len) > +{ > + enum bfd_endian byte_order = gdbarch_byte_order (m_descr->gdbarch); > + gdb_byte *regbuf; > + size_t regsize; > + T val; > + > + gdb_assert (regnum >= 0 && regnum < m_descr->nr_raw_registers); > + gdb_assert (!m_readonly_p); > + > + regbuf = register_buffer (regnum); > + regsize = m_descr->sizeof_register[regnum]; > + > + val = extract_integer (addr, addr_len, byte_order); > + store_integer (regbuf, regsize, byte_order, val); > + m_register_status[regnum] = REG_VALID; and maybe the need for all the templating. I.e., in the cases at hand, both the regcache buffer an the ADDR/LEN buffer are in target format, with the mismatch being in integer width (i.e., may need zero/sign extension or truncation), so it seems to me that we should be able to copy data to/from the register buffer directly, without having to convert to host format (the T / LONGEST) as an intermediate step. So basically if we start with that you have, what we'd need is a version of store_integer that takes a ADDR/LEN pair instead of a T val. Thanks, Pedro Alves