From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) by sourceware.org (Postfix) with ESMTPS id BFDB1384518D for ; Sat, 26 Nov 2022 01:42:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BFDB1384518D 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-oi1-x22b.google.com with SMTP id c129so6109877oia.0 for ; Fri, 25 Nov 2022 17:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding: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=w4t6WDvWic1agSlqyk6NXqCIZ7UicSKaM2qzpSU5wOo=; b=Pm4ifErA8hb3h0piWTtklo4r1p75sQ2pSkS25A+hvOnU3RCyBONNR8REHqzu9Kxefu ll0MprhEEfLANW5jEAZt2+Aah7Qavm2dfPS/dTMYNh8GANJMpM/ZqT6JOO0n/QH8C4Np G1rMd6NC1xAK/Qck0Naq6hW//DBAEyTaxaEyjcpnM4tzSj9dUR+z7dC6arJxmO+S+omz qXBhA2eFBgioyCSAgs5c+ueyAEflm6nscXUydwV7jRnxCpETo//nanPKJAr+aCWeKkjy aavWZzzvdzYnxYe6HhaljX1OLIDf+/iG+o3D6+khOkq3Iz2YT9UepqeeIPgzn7sdXF6L fGLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=w4t6WDvWic1agSlqyk6NXqCIZ7UicSKaM2qzpSU5wOo=; b=kArzOFmgwLjCqOeeI8l5V2egbmTT1ow9zN88kYLJ3YTo6ba2ROg+6r57svuqvA4Zpq aYjsM43k06frUziQ5lCDdJ0jFcEEHN4YwuYo9/HyHakMlKm6xRiV9s7Rg8IQsjGQId3i rmp2J3ys9BOur28fcvl9atOe57Lntc6hpyV7W8o5tQJvEBHIu6PKsSlDWfWEW84kMfY0 vo6Xo/Q6FzL7ZqAT11Bc8t30SFCmSggpHfgVYntLnN4vSzr8HswwQekBJgvJEHmWbWP8 30gLJ4t4evaiTAFeqZ1zQ1K05xeR99Z8rFPPUFWyQpxvJBJ2OEqiyf/70fddRdwidOzb 2Dcw== X-Gm-Message-State: ANoB5pn7ORLOY1AS1DT2kTGMOE4wz7PG6fcKcRLvtDgl3hcYo4sLUPrA Jpc9DWuEO7ALGCl40+zJGnfHLg== X-Google-Smtp-Source: AA0mqf7DJVLTJM4Zyrd2wWfUpa4hnVs4iy5RwBruO8FsB7QPDJz6e+kcVCVrlXWuelo4ezv6jVfkIw== X-Received: by 2002:aca:f302:0:b0:35b:451d:629e with SMTP id r2-20020acaf302000000b0035b451d629emr16451596oih.150.1669426933038; Fri, 25 Nov 2022 17:42:13 -0800 (PST) Received: from localhost ([2804:14d:7e39:8470:41ee:c7fc:c991:eee6]) by smtp.gmail.com with ESMTPSA id t12-20020a056870e74c00b001375188dae9sm2910251oak.16.2022.11.25.17.42.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Nov 2022 17:42:12 -0800 (PST) References: <20220908064151.3959930-1-thiago.bauermann@linaro.org> <20220908064151.3959930-4-thiago.bauermann@linaro.org> <6b12308f-d54a-129c-b8d9-5d34d09bb5bb@arm.com> User-agent: mu4e 1.8.11; emacs 28.2 From: Thiago Jung Bauermann To: Luis Machado Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 3/8] gdb, gdbserver/aarch64-linux: Allow aarch64_sve_get_vq to return error In-reply-to: <6b12308f-d54a-129c-b8d9-5d34d09bb5bb@arm.com> Date: Sat, 26 Nov 2022 01:42:10 +0000 Message-ID: <87y1ry8pal.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 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 9/8/22 07:41, Thiago Jung Bauermann via Gdb-patches wrote: >> If ptrace fails, aarch64_sve_get_vq assumes that SVE isn't supported. >> Because in a subsequent change this function will need to be called from >> low_new_thread (which can be called whe the inferior thread isn't stoppe= d), >> it will need to distinguish between ptrace errors due to SVE not being >> supported from ptrace errors due to the inferior thread not being stoppe= d. > > My understanding is that we will always be able to validate supported > features when we start/attach to a process. So if, say, we detect SVE > support through HWCAP's in the beginning of the debugging session, > that will still hold for any thread that is spawned. What may change > later on is the VL (still, very unlikely). I ended up dropping this patch when I implemented your idea of leaving the process' target description in place and using a thread target description only for the cases where it is needed (i.e., when the inferior supports SVE). It simplified the code a lot (thanks!), and it's not necessary any more to change low_new_thread so this patch became unnecessary. As an aside, we don't check for SVE support using HWCAP, just by getting the NT_ARM_SVE regset via ptrace. > When a thread is spawned, it will inherit SVE settings from its > parent. From the Linux Kernel SVE documentation: > > In particular, on return from a fork() or clone(), the parent and new c= hild > process or thread share identical SVE configuration, matching that of t= he > parent before the call. > > Is that something we can use here? I suppose there may be corner cases > where the parent spawned a thread and changed its VL size etc. It is, and for a while I had changes in my local branch which in the event of a clone or fork event copied the original thread's target description to the new one. After a while I noticed that in practice it was redundant, because when the new thread stops gdbserver calls aarch64_target::arch_update_tdesc which also sets up the thread's target description so I removed the changes for the clone and fork events. > If we can't and a thread is running, we won't be able to tell the VL, > but we have a state that is meant to indicate "unknown VL", don't we? > Maybe I'm misremembering, but -1 used to indicate that. We used -1 in struct gdbarch_info's id field, but it became unused in commit =E2=80=9CFix thread's gdbarch when SVE vector length changes=E2=80= =9D and was removed. We don't have an =E2=80=9Cunknown VL=E2=80=9D state anymore. And w= ith v2 of these patches, we can always use ptrace to get the VL so it's not needed. --=20 Thiago