From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2610:1c1:1:606c::19:2]) by sourceware.org (Postfix) with ESMTPS id 88AD1385ED71 for ; Wed, 26 Jan 2022 18:43:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 88AD1385ED71 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 882E2A1B1F; Wed, 26 Jan 2022 18:43:04 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JkXfJ0dJpz3q65; Wed, 26 Jan 2022 18:43:04 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643222584; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MSQ0hlqRiIhcsCeem8vLWeP4WsjQzKBxbJQRBsE4+es=; b=i3UjKdA/nFIqLh/iiN54bM0ddGntu8kdBZ8S5/MQhrkTt/S8cu7R9LMRvyhwKF3WQi1HkU 2Klf96EDkB525tCPvyTKGvjqKoR6TN5uDFOUaLk7JwzeF5/tZ/c9ZbeJ9Hk17wkM7eoErO NTR9HiYiBt/eXiEa2eXX3W++en2NaHImGenk/INL2qbbBZn9DMtu3iprJSgnOZG2x08xuN vgqdPOiXlr4hzNqBAjEdJZpLiBhUDxRw8WErbdY3GNmYmujv817pC9Gl6pHr+ac24KIW83 hn5skaxrf7mHNmUP6CXJzWC1fd5GVIKh3fPgrQCoXo0qbJF8QEalTrbZ8OZglQ== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id A2F37284D6; Wed, 26 Jan 2022 18:43:03 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <09cf22c2-d3ba-9516-1192-eef571a44ea2@FreeBSD.org> Date: Wed, 26 Jan 2022 10:43:02 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH 4/8] regcache: Zero-extend small registers described by a register map. Content-Language: en-US From: John Baldwin To: Andrew Burgess Cc: gdb-patches@sourceware.org References: <20210714140741.6460-1-jhb@FreeBSD.org> <20210714140741.6460-5-jhb@FreeBSD.org> <20211019083634.GD1693939@embecosm.com> <6d81aa7b-c5a9-d9eb-15ad-1ff56d78b9e3@FreeBSD.org> <4ce65e27-37c9-23dc-32b2-4d247703c123@FreeBSD.org> In-Reply-To: <4ce65e27-37c9-23dc-32b2-4d247703c123@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1643222584; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MSQ0hlqRiIhcsCeem8vLWeP4WsjQzKBxbJQRBsE4+es=; b=T3OnKXL4eK1RpWGzCICcp4DY1HjHISaWr8GxqZ6OorUPCGziI4smf8I/yvBY6Mzf6Z3m/G QR0P+qEbVej2uaZwrF/k49R3g/0QHmwq2OZvtGVJy3rGc0cirgZW4KP1j40SRSug3e450T SoVffBZrdAxTu7dva1UJLPbXST87CbzWBFlSaolliJAUu/asob3sAWPBu5DZvVjthUKPjM 4Mr3es7O0ZqVRv9yNdQZPnE9sppqdQw+lmOr3o145MrkTh6zVpDQWG6QZz1vZWtofWktCM rmDds16KGOG7JuKhrtVyxjiFVlztfioVkEQW1HUfBH71v+nA6EDBlLNyXlWVWw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1643222584; a=rsa-sha256; cv=none; b=P5AG6tclAheYiIIk78kU9+stctKwo47DKEvwW14aoWtAROtRrbzupiyuPDB5ofFbpFiJxW dYrgVr2sBynRqNYbbqRyYeuWv8Mh5F/CFL2avlbLikgT3GZtd6I/qs0nDw2h0DxN5R3geG FpL6cosQA8J/k0aBn+kbxunR5h6iVgAOxKCiBhJQNvpN9VJhFGaHk1pTbkGP9e9G+GBkvz TED9OlRgF5muZDi8OxWNDaYDwL9LQshRgjVe2n1bzg3K/5qbf7UE6SvGoKp5rJI7Oj6fRd wYJK13hhVcqVjZRa1sll3EfphaDaUK/wMelW4Fuu9GhEvWSqAHMmNNX6gSsEHA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP 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: Wed, 26 Jan 2022 18:43:08 -0000 On 12/22/21 1:20 PM, John Baldwin wrote: > On 10/26/21 2:17 PM, John Baldwin wrote: >> 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. > > Ping on the updated commit log message. Ping. -- John Baldwin