From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112349 invoked by alias); 24 May 2017 11:07:39 -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 112329 invoked by uid 89); 24 May 2017 11:07:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=transfers, unheard X-HELO: mail-wm0-f53.google.com Received: from mail-wm0-f53.google.com (HELO mail-wm0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 May 2017 11:07:37 +0000 Received: by mail-wm0-f53.google.com with SMTP id d127so63991224wmf.0 for ; Wed, 24 May 2017 04:07:41 -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=7BzJY3PyPeS5u2UqU0fhE09ZP/93lkEpf2uzikX/S34=; b=i3eJJaGlkjOf8RDeJ6kWQSn4954mk2jwhuD2gGiHCZv1d7u4br6L7BMTc/gba3bKsz PeS5p5IrFBvd0TkKVb9B9LQWMy9mpR/ddxMKfUo5kFu5U5YCMb6VXZujMxY0HBlH4C0H 2VvAmo4ZSPLilZ5fUGuUPfUxGQogGu/X1wJB9J8eE9xN0IKk5yzRH1sWc3Z2Q4ta+s7P Adpa9UNTvGO1KKh5d5EG76dhaL5WEsJMtJlYrQJGflJoSQBlN80N+vjkHOs8peJV384s mzNdSPXvWFY6NqTvyXkpkJAT/NrFAj8gxtaKSDLiEbyjA+tD2P39vnZPzi4pdDqTwZbg VoSg== X-Gm-Message-State: AODbwcC3KnOzSx6ope0ePk/EMnvSqgTlorEaoIDmWGXA/pef4MP1JQJE 1Fwk50wMV/UTJRtT X-Received: by 10.28.24.207 with SMTP id 198mr5391823wmy.86.1495624057987; Wed, 24 May 2017 04:07:37 -0700 (PDT) Received: from [192.168.0.102] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id y60sm5322483wrb.39.2017.05.24.04.07.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 04:07:37 -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> <40597975-9458-e9af-8915-9d303bb1ed98@redhat.com> Cc: Yao Qi , "gdb-patches@sourceware.org" , nd From: Pedro Alves Message-ID: Date: Wed, 24 May 2017 11:07: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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2017-05/txt/msg00522.txt.bz2 On 05/24/2017 11:20 AM, Alan Hayward wrote: >>> Meanwhile raw_collect_integer doesn’t need a signed parameter: >> >> Wouldn't we need to support ADDR_LEN larger than the register size? > > This might be me misunderstanding gdb, > But I assumed that addr would always be shorter than the register size. > If addr is bigger than the register size then the most significant bits will > be chopped off (including the sign), which I think would be a bad idea? Yeah, the case of a 32-bit register being given a 64-bit slot in a ptrace register buffer is actually not unheard of. For example the segment registers on x86-64 (cs, ss, ds, etc.) are 32-bit in gdb's register cache, but Linux ptrace transfers them as 64-bit [see /usr/include/sys/reg.h]. I'm not exactly sure whether in such cases we end up needing to sign/zero extend when copying back, or whether the kernel ignores the upper bits. I think that on x86 we just copy the lower 4 bytes and leave the upper ones as they were, so probably the latter. The MIPS architecture is special around addresses being signed though, and given the existing code, I'd play it safe and keep the collect/store functions mirrors - if one truncates, the other fills/extends, and vice versa. There's also /* Is the target using 64-bit raw integer registers but only storing a left-aligned 32-bit value in each? */ int mips64_transfers_32bit_regs_p; which most probably doesn't apply in this case (FreeBSD, while I think that was originally added for remote), but it compounds in the weirdness. Thanks, Pedro Alves