From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) by sourceware.org (Postfix) with ESMTPS id A1F6F3858D33 for ; Tue, 7 Feb 2023 14:39:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A1F6F3858D33 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-x235.google.com with SMTP id 20so11998422oix.5 for ; Tue, 07 Feb 2023 06:39:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; 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=cZcMWl41BM6IbvmzQfbBgqMELMbiJ0csBwe633xkdME=; b=Y2euIWtq0sFagKWYi0Uswh9PZG8hOJCMYxu/tYbWzMSl2l6BOxGuN5+kI5MlO5a9W/ +fHPZ8C6AamC5P/hLBSZAbAir2LXGXKQ9gNQ812Nv/K6gejT7uq+wpeGQ3lWQys7ZF1p 0DOg8BWJkgamKhv18q4bpkWATdj5aGyJ/U6JagXAeta65/3H2WGOOi3X/Q9bFkxVdsJR +MJIID4UdtsX+bDU0sWsbBI45wo+rG2I1+UcbWsi0vHiEfFZIqTcGQfRorQhILvRE64k rAeEwV9OtU4OnFppeIGkPx6KDqNdMlXmMFrDiR4bF0eFVKrOZ4Zq1vbu4AnxQk4HVo1w NmXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=cZcMWl41BM6IbvmzQfbBgqMELMbiJ0csBwe633xkdME=; b=OTiVwCAsYyJX+tvTnWmC6VL6WWgqATbZ2mBqTkFkZZMI75NFc5eUw+ibuFXMLweZ7J B0u1CfDQhT/2jgxhoV/eH0BN8+9lsJGGHv++XEQT0BtAaEMRKB/kek6WE6YdnCHwWcxj Cr76/ufYbIrfHTxbvmsI3skI+UALeSWkgEUiUf0vpJNWA620cMbobSGSeZOJsZg3ID7K qdmiCCX/LrU93apYl8KMQCl74jxOJFiSAxoZsUE8ZIi/i2+P/dMPqYFFtWTQznm3n1V0 tFxh7qOUMForfv4L9VRDMdwt3HTLhqDy9hTrgAMumd5Z2KjF5Ke6PX2xSAdw4l2/5vk2 xSpQ== X-Gm-Message-State: AO0yUKUPlgmi9dv+pUnl5TaolAgd9pkeCnGGeCmjvkIE7SZ3lUl7Gl4K euz/CWtvx/u06e/UCyMvdamShw== X-Google-Smtp-Source: AK7set+B6ASYL62SNi46PDDWXrm+ubBUhkwr6A7fVuAVdBZpJ3qoMkEEeXHmR+WhxoorJdSUH70qfQ== X-Received: by 2002:a05:6808:408c:b0:364:c9b7:bc with SMTP id db12-20020a056808408c00b00364c9b700bcmr1242701oib.56.1675780744922; Tue, 07 Feb 2023 06:39:04 -0800 (PST) Received: from localhost ([2804:14d:7e39:8470:e8eb:11fb:c659:ea2e]) by smtp.gmail.com with ESMTPSA id q19-20020a056808201300b00377fae9d36csm5622586oiw.52.2023.02.07.06.39.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Feb 2023 06:39:04 -0800 (PST) References: <20230130044518.3322695-1-thiago.bauermann@linaro.org> <20230130044518.3322695-5-thiago.bauermann@linaro.org> <87pmattzjw.fsf@redhat.com> <7970ac03-1123-d5f6-7b17-808832d43be6@simark.ca> <9a85e2fe-078a-e2ee-7e49-53fe0ceef492@arm.com> <87y1pgaib6.fsf@linaro.org> <9d30751a-589b-eb95-09b1-61d083ad9730@arm.com> <87leldmp6r.fsf@linaro.org> <045c1e09-5b6d-22b6-df7a-39cfa339b0e1@palves.net> User-agent: mu4e 1.8.13; emacs 28.2 From: Thiago Jung Bauermann To: Luis Machado Cc: Pedro Alves , Simon Marchi , Andrew Burgess , Thiago Jung Bauermann via Gdb-patches Subject: Re: [PATCH v3 4/8] gdbserver/linux-aarch64: When thread stops, update its target description In-reply-to: Date: Tue, 07 Feb 2023 14:39:02 +0000 Message-ID: <877cwtbkvt.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.3 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 2/6/23 20:29, Pedro Alves wrote: >> On 2023-02-04 3:21 p.m., Thiago Jung Bauermann via Gdb-patches wrote: >>> >>> Luis Machado writes: >>> >>>> On 2/2/23 03:47, Simon Marchi wrote: >>>>> Ok. Would it work if a new thread initially inherited the tdesc from >>>>> its process? >>>>> >>>> >>>> It should be fine because the first time we fetch a process target >>>> description, it is eventually obtained from the first and only thread. >>>> So the SVE vector length should be correct. >>>> >>>> Any subsequent attempts to use the process' target description (the >>>> first one we obtained), after further stops, may end up using an >>>> incorrect description. >>>> >>>> I think this is handled correctly by the target architecture target >>>> hook though. But there are other places where this is potentially >>>> incorrect. >>>> >>>> For example... >>>> >>>> - When using gcore to dump a core file, GDB only dumps a single target >>>> description. While this might be correct for a target with a fixed >>>> target description or a AArch64 target that doesn't support SVE, it >>>> likely won't be correctly for one AArch64 target supporting SVE if its >>>> threads changed vector length mid-execution. Either we emit target >>>> description notes by thread, or we don't emit a target description >>>> note for those cases. >>>> >>>> - When loading the above/older gcore core files back, GDB will use a >>>> potentially incorrect target description. If we decide to emit >>>> per-thread target descriptions, it should be fine. Otherwise we may >>>> need to have a "thread architecture" hook for core files as well. >>>> >>>> - The remote has no concept of a thread architecture (Thiago is >>>> addressing this with this patch series). >>>> >>>> - AArch64 frames may have slightly different vg values, which means >>>> their gdbarches are different as well. >>>> >>>> Given the differences between two gdbarches are small, we mostly get >>>> away with it. But if there are further differences (different hooks, >>>> for example), I fear we may run into a situation where we use an >>>> incorrect gdbarch to call a particular hook. >>> >>> Indeed, good points! Thank you for bringing them up. I can address core >>> file dumping/loading after this series. >>> >>> Regarding frames with different vg values, it's important to be aware of >>> this discrepancy but IMHO it makes sense to work on it when it becomes >>> a problem... >>> >> Yeah, one thought that keeps crossing my mind is if really modeling >> all this stuff as different target descriptions is really the best >> approach. The Intel AMX support posted on the list last year also ran >> into a similar problem, with the matrix registers height/width >> changing at runtime, and it is impractical (or really, it really >> smells like the wrong approach) to have different target descriptions >> for every potential matrix size. Which is not unlike different SVE >> sizes. It feels like a single tdesc should be able to be a bit more >> dynamic. It's a bit funny that ptrace manages to work with a single >> registers interface, while we don't. > > My understanding is that this was a bit hard to justify back when SVE > was implemented, as it would have to touch some other bits of the type > system to create a sizeless type for SVE vectors, where the size would > be determined by context. When I started working on these patches I read some older discussions on the topic of SVE in the mailing list archives and I saw this idea. So before going down the per-thread target description route I spent some time trying to figure out a way to make the vector register size a function of the contents of another register (a pseudo-register, in the case of SVE), but I failed to see how I could do it. I'm open to giving it another try but I would need some guidance. It doesn't need to be detailed instructions, but a high level idea of how it can be done would be very helpful. -- Thiago