From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41011 invoked by alias); 28 Oct 2018 16:47:14 -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 40999 invoked by uid 89); 28 Oct 2018 16:47:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=adjusted, morgan, force, Morgan X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 28 Oct 2018 16:47:12 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w9SGl5tF007713 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 28 Oct 2018 12:47:10 -0400 Received: by simark.ca (Postfix, from userid 112) id 85D4D1EA6F; Sun, 28 Oct 2018 12:47:05 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 291A01E4C2; Sun, 28 Oct 2018 12:47:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 28 Oct 2018 16:47:00 -0000 From: Simon Marchi To: Bill Morgan Cc: gdb@sourceware.org Subject: Re: win32-arm-low.c regptr 96 bits stored in 32 bit variable In-Reply-To: References: Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2018-10/txt/msg00055.txt.bz2 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