From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id E6F073858C1F for ; Tue, 22 Nov 2022 22:16:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E6F073858C1F 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 4NGz9g30vyz3TRj; Tue, 22 Nov 2022 22:16:07 +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 4NGz9g29Dbz4Kkm; Tue, 22 Nov 2022 22:16:07 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669155367; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=johRiHaKZwGy99fGm7j56xzPxeqX7hFKiVExxBD4Lpo=; b=aPoSCxe6yLjKUS1I1TwPz31pXLfklHKvDuAFBVbvNFSgkifQLq6pxHrcnXgzSA5douKTI6 DMc+bSGWjbaOKNYwulTAh3A84uwhBvQrFPeWWB+6G0AYX/qx7aI4FcRyVsBYAv9ZiCUf3p YNsHy5MM41ZWNqHgNvis/iXvi/eABz+y479pNrVsTtRUJ+ebHA1gbcHjeBSfWslL23jEEl cQ4ln+y9KifLOO6q4wBEcqXpcooV8ZJFCUai6Q1sJ4c9nhLnYpsyqKAvzerRdFKSXL5uuq vGrZsljxdlz/SNr6MNZ3F9nWo+JrIUeGOV/EY3ytIsx9ayxxEWwdwsu3X4k1/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1669155367; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=johRiHaKZwGy99fGm7j56xzPxeqX7hFKiVExxBD4Lpo=; b=qTcr4GIcdy2WCTqcoB82q+fBWkj0S8BAHVul645Ncbuw+CoD3Jtk87zGTwzSUN6CkndmiF pj940xLUTIxQbaoWgKbzpCbko243xAFcBjDBB1LszHoCcCxINm2FRPJRc7Py1AwEKsOxdq ERUI+bF7iOFWQ+CP4BtzU9M4+w9QIgYCCmVptGUDC2ZuJIDBrhjcu3Gz++zM3cA9wdKwoT apeoSjqQnfLEnvFieSfNB6RtIZGVerFDM6KHDzingiyU6Iha0tYYW+7lLJ2kB68tl5t4ks Vdx2ZIpgknHI5FJqgFeAWswxC5V/GOE2PD3ByqWFX8NYdh5/KS+PwTkFEWN+jw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1669155367; a=rsa-sha256; cv=none; b=UtKwmIWWXB447ZVxknD7Wf1ARdQxlFuX0YrZSsvliyyFhdtiLinL5aB6ARiNanMugH9t7f jR9605EgB99AKMcYg7dXeoGrfeTY6hXzZxTUrdjxCiWUm+P2nBrkuRcrbYYBFvuz3PlDJW pSIncmczUR0YOnMNB67b3T+Ig3wJhydxc28kVyubfYkiQHN794LXMK55FBYb7zvYnUMdXx JdNkPxeqTYN62+ezTumnnXES4FamiX3MVm0wK7iIw/i0RvbFkainMa0JMfyYvgrO7QejMM B7aKei5PGh91qy2Sqj7M3g4MXLe5qS1mhscRy1XgjsZPA605G+hRp1LwrUpteg== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4NGz9f69pxzb44; Tue, 22 Nov 2022 22:16:06 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Tue, 22 Nov 2022 14:16:05 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org References: <20220708005816.9408-1-jhb@FreeBSD.org> <20220708005816.9408-4-jhb@FreeBSD.org> <7fc99741-64d8-f213-ea64-aa401bd42d4c@simark.ca> From: John Baldwin Subject: Re: [PATCH 3/5] fbsd-nat: Pass an optional register base to the register set helpers. In-Reply-To: <7fc99741-64d8-f213-ea64-aa401bd42d4c@simark.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 11/22/22 12:38 PM, Simon Marchi wrote: > On 7/7/22 20:58, John Baldwin wrote: >> This is needed to permit using the helpers for register sets with a >> variable base. In particular regnum needs to be converted into a >> relative register number before passed to regcache_map_supplies. >> --- >> gdb/fbsd-nat.c | 34 +++++++++++++++++++--------------- >> gdb/fbsd-nat.h | 49 ++++++++++++++++++++++++++++--------------------- >> 2 files changed, 47 insertions(+), 36 deletions(-) >> >> diff --git a/gdb/fbsd-nat.c b/gdb/fbsd-nat.c >> index 9d7383ac0ab..edcd3fc3ed1 100644 >> --- a/gdb/fbsd-nat.c >> +++ b/gdb/fbsd-nat.c >> @@ -1732,14 +1732,15 @@ fbsd_nat_target::supports_disable_randomization () >> bool >> fbsd_nat_target::fetch_register_set (struct regcache *regcache, int regnum, >> int fetch_op, const struct regset *regset, >> - void *regs, size_t size) >> + int regbase, void *regs, size_t size) >> { >> const struct regcache_map_entry *map >> = (const struct regcache_map_entry *) regset->regmap; >> pid_t pid = get_ptrace_pid (regcache->ptid ()); >> >> - if (regnum == -1 || regcache_map_supplies (map, regnum, regcache->arch(), >> - size)) >> + if (regnum == -1 >> + || (regnum >= regbase && regcache_map_supplies (map, regnum - regbase, >> + regcache->arch(), size))) > > My understanding is that it would be an internal error if the caller > passed a regnum that is < regbase. In order words, should you do: > > gdb_assert (regnum >= regbase); > > ? > > Actually, after reading the following patches, I think the answer is > no. When requesting a single register, we will still go through all the > fetch functions and we expect them to do nothing if the register is not > theirs. Leaving the question there in case others wonder about the same > thing. > > I was also wondering if it would be better to do the absolute -> > relative conversion in the caller. All this function knows is the > regset-relative view of things. In the end it doesn't matter much, it > just moves a condition from here to the callers. I'm fine with whatever > you prefer. If you do the adjustment to an absolute value in the caller you have to still special case for regnum == -1 when fetching all registers. The current approach here means that the special case for that is handled down in regcache:transfer_regset which already has a special case for -1. -- John Baldwin