From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +RS1G7EXw2QRHTEAWB0awg (envelope-from ) for ; Thu, 27 Jul 2023 21:19:45 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=lZYAKWaI; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 6457F1E0C0; Thu, 27 Jul 2023 21:19:45 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 4A5111E00F for ; Thu, 27 Jul 2023 21:19:43 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7E1C038555A0 for ; Fri, 28 Jul 2023 01:19:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7E1C038555A0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1690507182; bh=BfdwYiw8zPUH6ZyCUEmMW+8nyb3cwlcZkAlidTmhzKw=; h=References:To:Cc:Subject:In-reply-to:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=lZYAKWaIIRWfEj/ZoorKYz8iGC2edm0gEZU4QGiJEfy/o0QV9oQbk35XtLfaHYNWE 9TWpqud31lov0bNzsf/nVFqzKyguBzp0u6wpgAosr6oTOE/jBZGrc3vU8kM3yxHNog B+k+3WToHubutQfr04EimXKRK5A51p7Mux6IRaN0= Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) by sourceware.org (Postfix) with ESMTPS id 9BC873856090 for ; Fri, 28 Jul 2023 01:19:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9BC873856090 Received: by mail-oo1-xc35.google.com with SMTP id 006d021491bc7-564e4656fecso1107665eaf.0 for ; Thu, 27 Jul 2023 18:19:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690507160; x=1691111960; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=BfdwYiw8zPUH6ZyCUEmMW+8nyb3cwlcZkAlidTmhzKw=; b=cC8JZ/qllut0vMwk0HSgs4IvScdeH17LJ6VwbpOg7jtlU8QKiZQXgIpeOBzZEdys14 Gec8s9uWAGmCq1mkM52HsNJxfHx6eiY+wzv1jVWIo8RZkSPYvGIv6GxoRnzUVsCKbb4C Q4nG9yhIPSZMfAawz5OfAh31T/OktyRtgaj+/rldwvWGdK1XOeH9kqzy2RaQRMf6bag/ SHiS3rTkmTDhInE5ngqYQ5TXR+Bdk1mYCupETUjpmq6Wj4+9ieMzdS/hsHmUEx6r6cyQ 0Bwu0qsw7+zl1nJri9ZMQ/eMUnGU2SP0671v2EDo0W7yr/cYLiZ3SYx2bINdF2ck59qL dB5A== X-Gm-Message-State: ABy/qLaXrIV7Sr614/UgUET8ffUJODi8xsnYU4WS/fpd9APtOZSUSvvb 10aELnj6Dyv+CJ1HaGcgQKc8QQ== X-Google-Smtp-Source: APBJJlEXcWX27ijFovDdKg2Yphnx0zq1KTI3hBlm922+Q0ToNxtvPXdukfLEbZPZVYp3U0Lp/zGCzg== X-Received: by 2002:a4a:3557:0:b0:566:f51f:bbd3 with SMTP id w23-20020a4a3557000000b00566f51fbbd3mr1253661oog.2.1690507160592; Thu, 27 Jul 2023 18:19:20 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8470:b6b2:cb77:8e91:bbbd]) by smtp.gmail.com with ESMTPSA id v14-20020a4a974e000000b00566250a04f6sm1159977ooi.18.2023.07.27.18.19.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Jul 2023 18:19:20 -0700 (PDT) References: <20230630134616.1238105-1-luis.machado@arm.com> <20230630134616.1238105-6-luis.machado@arm.com> <87pm4e8ms4.fsf@linaro.org> <317fa7b7-800e-87e0-1118-acaf9d1c1008@arm.com> User-agent: mu4e 1.10.5; emacs 28.2 To: Luis Machado Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v3 05/16] [gdb/aarch64] sme: Enable SME registers and pseudo-registers In-reply-to: <317fa7b7-800e-87e0-1118-acaf9d1c1008@arm.com> Date: Thu, 27 Jul 2023 22:19:16 -0300 Message-ID: <87fs587rzf.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, 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 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: , From: Thiago Jung Bauermann via Gdb-patches Reply-To: Thiago Jung Bauermann Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Luis Machado writes: > On 7/26/23 21:01, Thiago Jung Bauermann wrote: >> >> Hello, >> >> Just minor nits... >> >> >> Luis Machado via Gdb-patches writes: >> >>> @@ -890,21 +959,27 @@ aarch64_linux_nat_target::thread_architecture (ptid_t ptid) >>> if (gdbarch_bfd_arch_info (inf->gdbarch)->bits_per_word == 32) >>> return inf->gdbarch; >>> >>> - /* Only return it if the current vector length matches the one in the tdep. */ >>> + /* Only return the inferior's gdbarch if both vq and svq match the ones in >>> + the tdep. */ >>> aarch64_gdbarch_tdep *tdep >>> = gdbarch_tdep (inf->gdbarch); >>> uint64_t vq = aarch64_sve_get_vq (ptid.lwp ()); >>> - if (vq == tdep->vq) >>> + uint64_t svq = aarch64_za_get_svq (ptid.lwp ()); >>> + if (vq == tdep->vq && svq == tdep->sme_svq) >>> return inf->gdbarch; >>> >>> - /* We reach here if the vector length for the thread is different from its >>> + /* We reach here if any vector length for the thread is different from its >>> value at process start. Lookup gdbarch via info (potentially creating a >>> - new one) by using a target description that corresponds to the new vq value >>> - and the current architecture features. */ >>> + new one) by using a target description that corresponds to the new vq/svq >>> + value and the current architecture features. */ >>> >>> const struct target_desc *tdesc = gdbarch_target_desc (inf->gdbarch); >>> aarch64_features features = aarch64_features_from_target_desc (tdesc); >>> features.vq = vq; >>> + /* We cast to uint8_t here because the features struct can get large, and it >>> + is important to store the information in as little storage as >>> + possible. */ >> >> Is it because features is used as a key in tdesc_aarch64_map? Mentioning >> in the comment why it needs to be small would be useful. >> > > I've changed this to: > > /* The svq value in the features struct is stored as uint8_t, so cast it > properly in here. */ > > It makes me wonder if this cast is useful though. Technically we will implicitly cast > it to uint8_t anyway, so the value will be truncated. When we hash things into feature > bits, it will be handled properly. There are other places which assign an uint64_t to features.svq without the cast, so I also think it's not really needed here. > I'm considering removing the comment altogether and just doing the assignment with the > implicit conversion. I agree. But it's useful to be aware that even though GDB mostly works with svq of 64 bits even though this field is 8 bits, so perhaps add a comment to that effect to the definition of features.svq in aarch64.h? >>> + features.svq = (uint8_t) svq; >>> >>> struct gdbarch_info info; >>> info.bfd_arch_info = bfd_lookup_arch (bfd_arch_aarch64, bfd_mach_aarch64); >>> +/* See nat/aarch64-scalable-linux-ptrace.h. */ >>> + >>> +bool >>> +write_sve_header (int tid, const struct user_sve_header &header) >>> +{ >>> + struct iovec iovec; >>> + >>> + iovec.iov_len = sizeof (header); >>> + iovec.iov_base = (void *) &header; >> >> Unnecessary cast. >> > > Turns out this is necessary, as otherwise we'll get a complaint about trying to assign a > (const void *) > to (void *). Same for the other const struct cases where we write headers. Ah, sorry about the false alarm. -- Thiago