From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oo1-xc35.google.com with SMTP id 006d021491bc7-564e4656fecso1107665eaf.0 for ; Thu, 27 Jul 2023 18:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1690507160; x=1691111960; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=BfdwYiw8zPUH6ZyCUEmMW+8nyb3cwlcZkAlidTmhzKw=; b=Qgy9yz7Zp+B8J4UEEL64mGAdoQrU864Cp9e3i2J1aRKLDgSPsh7n8N1X+AP5WfYsWs QybXM59hlE32JShoYMKmI2ZGHDZsrz+RisGO6Ld0dQO8xMDnX9fEY0eVBf8IyOJfqWlO eZ6QRjNsleyA4HDuw5Ef5s2ZMTp2ntKfutxdM5g3lsu/5frSgLst3xv4Vzud/iOZUfyZ CDGtwIaDnZ53XdBlzyrEb6Sqco+Nk7WqIrgfWBP6OVQV2muzLb+HejRGDMIumgsU48Ao pMFMKUsbn3EXikIpCxARdXOTC67AqAm6dd1t2GE4z0SGjkVGTLHG92hd566PtswncRDc hSmg== 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 From: Thiago Jung Bauermann 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 List-Id: 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