From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 7B5D3385840C for ; Fri, 28 Jan 2022 15:43:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7B5D3385840C Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-518-Le2nDssJMH2yIwrRHO-HMA-1; Fri, 28 Jan 2022 10:43:23 -0500 X-MC-Unique: Le2nDssJMH2yIwrRHO-HMA-1 Received: by mail-wm1-f72.google.com with SMTP id n7-20020a1c7207000000b0034ec3d8ce0aso3109212wmc.8 for ; Fri, 28 Jan 2022 07:43:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=x7jxuQolj6oql7QbrveJWZA9v4GFCCPBZ6M7Meyjl3I=; b=jkJMIGWIVaIPgikYFWCmtwJPb/FDP96wJC9nK2WdlnfU87mZ9aMi9eZqD0egIL7MLS I6pn60w5i36/ypvM/vZ/rZDukJ+o9lYRltjrvCwRA7ssNnVwMdLzhFDjTf9/7Q/5pimO 31+mhz0hsGcdDMzSqnsPzWeE8/fjs55QFzVg2wCofJzR/FPMe0vnADavzN7ZeyDGdNDP rwvvhdCXpM5mMzzZWGjOuh3TVK+mGIi8ED2ftUK//UM0BMHyUaUTmaG70iUH3OHleu/i 7zB5vdBjQYF8qMRvOgojvsbanMi9XB4KsOKkEQxVXVLEZl/UO8ToSd1vnZcrmAzDchbm OYdQ== X-Gm-Message-State: AOAM5335xvfTSdaqBiWAQKsvuYEM+w8gpQfNjQv3fYC7UGkbJTolpe97 L5RhA9VBEPj+OsoIhp8swJk+bve+y3Se2LWg/jr30/s5yeVuDfyLM0VWWakASNnhLyOCrPZlOqc 0rg/m/gZ0Pt/uiPUxD+l9Nw== X-Received: by 2002:adf:f90c:: with SMTP id b12mr7420367wrr.97.1643384602653; Fri, 28 Jan 2022 07:43:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJzf7fmwGe0sRtipMetlCzB5eMUt/NxiNx9D3IYWRH1HS/2MHNrGX/zT3d8FhKUOgidmmHR13A== X-Received: by 2002:adf:f90c:: with SMTP id b12mr7420356wrr.97.1643384602432; Fri, 28 Jan 2022 07:43:22 -0800 (PST) Received: from localhost (host86-140-92-93.range86-140.btcentralplus.com. [86.140.92.93]) by smtp.gmail.com with ESMTPSA id f5sm4789214wrq.87.2022.01.28.07.43.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Jan 2022 07:43:22 -0800 (PST) Date: Fri, 28 Jan 2022 15:43:20 +0000 From: Andrew Burgess To: John Baldwin Cc: Andrew Burgess , gdb-patches@sourceware.org Subject: Re: [PATCH 4/8] regcache: Zero-extend small registers described by a register map. Message-ID: <20220128154320.GD425591@redhat.com> References: <20210714140741.6460-1-jhb@FreeBSD.org> <20210714140741.6460-5-jhb@FreeBSD.org> <20211019083634.GD1693939@embecosm.com> <6d81aa7b-c5a9-d9eb-15ad-1ff56d78b9e3@FreeBSD.org> MIME-Version: 1.0 In-Reply-To: <6d81aa7b-c5a9-d9eb-15ad-1ff56d78b9e3@FreeBSD.org> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 15:39:32 up 4 days, 6:26, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 15:43:26 -0000 * John Baldwin [2021-10-26 14:17:36 -0700]: > On 10/19/21 9:31 AM, John Baldwin wrote: > > On 10/19/21 1:36 AM, Andrew Burgess wrote: > > > * John Baldwin [2021-07-14 07:07:37 -0700]: > > > > > > > When registers are supplied via regcache_supply_register from a register > > > > block described by a register map, registers may be stored in slots smaller > > > > than GDB's native register size (e.g. x86 segment registers are 16 bits, > > > > but the GDB registers for those are 32-bits). regcache_collect_regset > > > > is careful to zero-extend slots larger than a register size, but > > > > regcache_supply_regset just used regcache::raw_supply_part and did not > > > > initialize the upper bytes of a register value. > > > > > > > > trad_frame_set_reg_regmap assumes these semantics (zero-extending > > > > short registers) as I had misread the implementation of > > > > regcache::transfer_regset and assumed it zero-extended short > > > > registers. In my specific use case (x86 segment registers stored as > > > > 16-bit values), I need the semantics of zero-extending a register > > > > value in a smaller slot. > > > > > > I don't claim to know if anyone relies on the old behaviour of > > > transfer_regset_register, but the change you propose seems reasonable. > > > > > > However, the second paragraph of your commit message really confuses > > > me. > > > > > > It seems to say that a mistake was made in trad_frame_set_reg_regmap, > > > and so transfer_regset_register should change, then you just jump to > > > saying you need the zero extend. I don't really understand the > > > connection between all these ideas. > > Here's an updated log message that hopefully is clearer: > > regcache: Zero-extend small registers described by a register map. > > When registers are supplied via regcache_supply_register from a > register block described by a register map, registers may be stored in > slots smaller than GDB's native register size (e.g. x86 segment > registers are 16 bits, but the GDB registers for those are 32-bits). > regcache_collect_regset is careful to zero-extend slots larger than a > register size, but regcache_supply_regset just used > regcache::raw_supply_part and did not initialize the upper bytes of a > register value. > > trad_frame_set_reg_regmap assumes these semantics (zero-extending > short registers). Upcoming patches also require these semantics for > handling x86 segment register values stored in 16-bit slots on > FreeBSD. Note that architecturally x86 segment registers are 16 bits, > but the x86 gdb architectures treat these registers as 32 bits. Sorry for the delay, I lost track of this series. Thanks for the updated message, I think this is clearer. I still wonder if there could ever a case where, if the type of a register was signed, we should be sign extending, rather than zero extending... ...but given that, such a situation must already be broken, I'm assuming that isn't something that exists today. As such, and with lack of comment from anyone else, I think this is good to go. Thanks, Andrew