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 D5BA53858C62 for ; Thu, 30 Nov 2023 23:44:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D5BA53858C62 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D5BA53858C62 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=2610:1c1:1:606c::19:2 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701387875; cv=pass; b=Hyw7N8GxX7/Y0WcdDo5ML4O2UbdqppdA9lAUb1hlyCb0wcX2K2Qfmrw5kZJ7jGljh2wcYywUOklfy6zbEIvAmGMdB+hgpfCMbCyp8b6peGH1kFayGWrwwEQ/92bUORwAGjYpEyz1ffsHy2NaoQoYROSSY/0F33aLwwYYPXsruEQ= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701387875; c=relaxed/simple; bh=uF6yur+dquilWqd3SLzZ0Rz5X7UPfXTwtZZ1odvCy2A=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=CZkK84E1l4Ts0rwBtXuNTtPTIpwLSkWA9OWhLhRYAhQCaiycb7Vo6bu3NrMRuY61kZoDN2/4S/qN37idfwkqKW3KQMvcKOuQnbvOuftcHKD+WXYvxLqdZiM64VSNufYj4IhEcJIY21fwqzazfxggx0+QhnD94vhvl25tMlmiKik= ARC-Authentication-Results: i=2; server2.sourceware.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 4ShCTV2my4z3MNR; Thu, 30 Nov 2023 23:44:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4ShCTV1nwbz3ggW; Thu, 30 Nov 2023 23:44:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1701387870; 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=3Pwy2LH0hjX5fY4TukZrWrFJEgZGuMZ4Pa9r524xH8I=; b=ZPdsOEaMx1piUgVzRMRqr3UQdERLyu9DAbGlprQHaHADo4Lxg5sZsOzz2+NogbIDmiCrth +n4QmgYfw1GmaTHztpNHq7GdhoZVMNWffCfFARwBq42Rm+EKNTgvx+Ex2Urswt6ivaKv8c nehxa1KANou8ek3GLWBVyEqfdMH8yV8PVC4iezT8eCsQkNKb3v+tJYoE9mHy3zoVQyxZrT BD4g7GmwRZGxRVgCllOvtxWV8j4V+5spdWFb4rXd5lUwx/7gElxDhQFiwqwFHf+zhkT3jD 63PSV/bA/vQlIKlxbaNX0ddoXzzdU9xCKIBNbxVwozRa1+C4h3zSNDRHfo/ORA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1701387870; 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=3Pwy2LH0hjX5fY4TukZrWrFJEgZGuMZ4Pa9r524xH8I=; b=QOr7LsIr80HS40rRDzQ4IbwEUgFEb+HXWKDxqGjl+OF3SZPgi1Y65iVBKN06a9x6pUB4X2 TwfFlsq7C70L2suQeT0SAQgqPV5z0K1GAaCVwgN/8n/5TwQ7T90OVbTXi9ltiMDxzFJDdz I2sW9Mn2hMNUZB0cbIMSlIbf22ueNXT7x5Ynx/yk6yEEvjIi1rNi903N7W1CuNWYU7W5Rx WISxUst+p04gicZEDs5/WVOMVaSAn19HpLGszfKv3DoYAKjZtateeqSdMbuYXVYM0+excx obFwLYteu7A5no4d+gRgTT7gvMs6M8hr1dvYALWmaq/WSHd4hcggusY1UtIQSw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1701387870; a=rsa-sha256; cv=none; b=Dee3XT16gYXIouDcLSLqYaW8wFi31p/5cuVr+h4Ru1wwka0L8xqrBvPbyZyylc4qQrG9rS U5WlaQmqHthQyvcFwwCmGG19c5Q8WX18QCObU9Si2xfDsn+95aBELYq8ZKWLFeiOcd/PXL +BYd1/bXYXuOrZ6CcQ2ZN97AQ67fXCz0lSxqbY+X+qghQNYhUiINiBiVkpPepkVTO59kVd WWiE9PiRG+7eR5nPpPQk6GhQp5/68oYwnTG10o8Xe0JFd4ce+zAppohU2Ge6xRx+2gyrs4 y5FND/CPv+SsRvAJNmkzpyO5ioVn4BHi/hIJIybwGaMzp1mqKdP/B7c9dXjjLA== Received: from [IPV6:2601:648:8384:fd00:b889:21c7:e7ab:a49f] (unknown [IPv6:2601:648:8384:fd00:b889:21c7:e7ab:a49f]) (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 4ShCTT5dB3z1rQ; Thu, 30 Nov 2023 23:44:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <35bb604e-f42f-4112-bdac-819c403281bc@FreeBSD.org> Date: Thu, 30 Nov 2023 15:44:28 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] gdb: add missing regcache_map_entry array null terminators in aarch64-linux-tdep.c Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org Cc: Luis Machado References: <20231130212057.722990-1-simon.marchi@efficios.com> <20231130212057.722990-3-simon.marchi@efficios.com> From: John Baldwin In-Reply-To: <20231130212057.722990-3-simon.marchi@efficios.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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/30/23 1:20 PM, Simon Marchi wrote: > Fix two spots in aarch64-linux-tdep.c that build regcache_map_entry > arrays without a null terminator. The null terminators are needed for > regcache::transfer_regset to work properly. > > Some shower thoughts: I'm wondering: if a caller uses > supply_regset/collect_regset with a regcache_map_entry array that > describes exactly X bytes, and passes a buffer of X bytes, should a null > terminator really be needed? regcache::transfer_regset could be written > in a way that it exits as soon as the remaining buffer size reaches 0. > Right now, even when it has consumed exactly the X bytes of the buffer, > transfer_regset needs to read the following regcache_map_entry's count > (expected to be 0) to realize it's done. If it exited its outer loop > when `offs == size`, it would remove the need for the null terminator in > this case. regcache_map_entry_size depends on a nul terminator as it is computing a size, not taking a register block size as input. > Shower thought #2: we could also bypass that by using array_view to pass > regcache_map_entry arrays, removing the need for null terminators > altogether, but that's a bigger change. I do think this is the better long-term solution. > Change-Id: I3224a314e1360b319438f32de8c81e70ab42e105 > --- > gdb/aarch64-linux-tdep.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/gdb/aarch64-linux-tdep.c b/gdb/aarch64-linux-tdep.c > index cd99b33fed25..5be887a9c817 100644 > --- a/gdb/aarch64-linux-tdep.c > +++ b/gdb/aarch64-linux-tdep.c > @@ -1497,7 +1497,9 @@ aarch64_linux_iterate_over_regset_sections (struct gdbarch *gdbarch, > /* Create this on the fly in order to handle the ZA register size. */ > const struct regcache_map_entry za_regmap[] = > { > - { 1, tdep->sme_za_regnum, (int) std::pow (sve_vl_from_vq (tdep->sme_svq), 2) } > + { 1, tdep->sme_za_regnum, > + (int) std::pow (sve_vl_from_vq (tdep->sme_svq), 2) }, > + { 0 } > }; > > const struct regset aarch64_linux_za_regset = > @@ -1518,7 +1520,8 @@ aarch64_linux_iterate_over_regset_sections (struct gdbarch *gdbarch, > { > const struct regcache_map_entry zt_regmap[] = > { > - { 1, tdep->sme2_zt0_regnum, AARCH64_SME2_ZT0_SIZE } > + { 1, tdep->sme2_zt0_regnum, AARCH64_SME2_ZT0_SIZE }, > + { 0 } > }; > > /* We set the register set size to REGSET_VARIABLE_SIZE here because Reviewed-By: John Baldwin -- John Baldwin