From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89462 invoked by alias); 29 Oct 2018 13:50:18 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 89445 invoked by uid 89); 29 Oct 2018 13:50:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=BAYES_50,SPF_PASS autolearn=ham version=3.3.2 spammy=morgan, Morgan, Always, xmlarch X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Oct 2018 13:50:16 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 57E5B80D; Mon, 29 Oct 2018 06:50:15 -0700 (PDT) Received: from e120077-lin.cambridge.arm.com (e120077-lin.cambridge.arm.com [10.2.206.194]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8DF5D3F71D; Mon, 29 Oct 2018 06:50:14 -0700 (PDT) Subject: Re: win32-arm-low.c regptr 96 bits stored in 32 bit variable To: Simon Marchi , Bill Morgan Cc: gdb@sourceware.org References: From: "Richard Earnshaw (lists)" Openpgp: preference=signencrypt Message-ID: <63e27524-6e86-eae2-8cd7-4482f5cda5a4@arm.com> Date: Mon, 29 Oct 2018 13:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-10/txt/msg00059.txt.bz2 Surely nobody is interested in the long-dead FPA architecture these days. I'm not sure why GDB still supports it. R. On 28/10/2018 16:47, Simon Marchi wrote: > On 2018-10-26 18:40, Bill Morgan wrote: >> Should this static variable ULONG zero be at least 96 bits? >> >> static char * >> regptr (CONTEXT* c, int r) >> { >>   if (mappings[r] < 0) >>   { >>     static ULONG zero; >>     /* Always force value to zero, in case the user tried to write >>        to this register before.  */ >>     zero = 0; >>     return (char *) &zero; >>   } >>   else >>     return (char *) c + mappings[r]; >> } >> >> reg-arm.dat shows 96 bits for the ones that have mappings[r] == -1 >> >> name:arm >> xmlarch:arm >> expedite:r11,sp,pc >> 32:r0 >> 32:r1 >> 32:r2 >> 32:r3 >> 32:r4 >> 32:r5 >> 32:r6 >> 32:r7 >> 32:r8 >> 32:r9 >> 32:r10 >> 32:r11 >> 32:r12 >> 32:sp >> 32:lr >> 32:pc >> 96:f0 >> 96:f1 >> 96:f2 >> 96:f3 >> 96:f4 >> 96:f5 >> 96:f6 >> 96:f7 >> 32:fps >> 32:cpsr > > Hi Bill, > > By inspection, it does seem like a mistake, and that we would need to > return a pointer to a buffer at least as big as register r.  But I have > no idea how to build/run/test gdbserver on win32/arm.  If you are able > to confirm that there is a problem and test a fix, could you please > provide a patch? > > To avoid this kind of problem again, we could return a pointer to a > dynamically-sized buffer adjusted to the size of the register.  > Something like this: > > static char * > regptr (CONTEXT* c, struct regcache *regcache, int r) > { >   if (mappings[r] < 0) >   { >     static gdb::byte_vector zero; >     /* Always force value to zero, in case the user tried to write >        to this register before.  */ >     zero.assign (regcache_register_size (regcache, r), 0); >     return (char *) zero.data (); >   } >   else >     return (char *) c + mappings[r]; > } > > Simon