From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18262 invoked by alias); 22 Jan 2020 17:04:11 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 18254 invoked by uid 89); 22 Jan 2020 17:04:11 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*Ad:U*gdb, H*f:sk:39da275, H*MI:sk:39da275, H*i:sk:39da275 X-HELO: mail-qt1-f196.google.com Received: from mail-qt1-f196.google.com (HELO mail-qt1-f196.google.com) (209.85.160.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Jan 2020 17:04:09 +0000 Received: by mail-qt1-f196.google.com with SMTP id h12so128215qtu.1 for ; Wed, 22 Jan 2020 09:04:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=AxoVyZ314ZpzJIfhJyCbVw/DdOdqTRk8eiJ6cOzuxtc=; b=S7fMQPu+G39d0pNL5tXKIw/idaQ7GXd3kgat2AMSijFOd1zleLmNAmOxAeHa0cMpN8 pWQnXfpxR2n3cPgCyQSOfz625t9w16+KuIpNkeobN1QbwVwlkbzb+HlnE4S1ijSWaFFA pf48K2Tm8PFkAnytHao40cn9rMwjKfTmnEx/pO1N17LyMjE7HhNBAspfe0UvVlgymwQu nnpQ1HyAZTlBVBYBAApiBH73Ox0wRGCxEBDiEtVBVPSTCc0tyL8nm//Zk7GIaXgwEhgr U2oDLjZFJFBn5szcYIvXxIrfhFndykdSjMNz+j1mT92FGOqzyOnTovWMJgWlXcVoCyoh djRA== Return-Path: Received: from [192.168.0.185] ([177.158.84.16]) by smtp.gmail.com with ESMTPSA id g18sm21655521qtc.83.2020.01.22.09.04.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Jan 2020 09:04:06 -0800 (PST) Subject: Re: [RFC] Changing gdbarch mid-execution From: Luis Machado To: Pedro Alves , "gdb@sourceware.org" , Alan Hayward References: <4f30e9b5-d196-1dc5-7713-6c42e7d9494d@linaro.org> <69c1ca6c-d4d5-9d04-1115-3c9bdda3139f@redhat.com> <39da275d-ccac-4f47-b666-377f7e099da5@linaro.org> Message-ID: Date: Wed, 22 Jan 2020 17:04:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <39da275d-ccac-4f47-b666-377f7e099da5@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00041.txt.bz2 CC-ing Alan as well. On 1/22/20 2:03 PM, Luis Machado wrote: > On 1/22/20 11:56 AM, Pedro Alves wrote: >> On 1/6/20 2:08 PM, Luis Machado wrote: >>> Hi, >>> >>> I have a situation at hand and i'm thinking about how to best solve it. >>> >>> AArch64 SVE has the capability of changing the vector length >>> mid-execution. This can be done at the thread level. >>> >>> Native GDB already supports this by looking at the ptrace data. But >>> doing this for a remote target requires changes to the RSP. >>> >>> Instead of changing things just for this particular case, i'm >>> considering having a more general mechanism for updating the >>> architecture data whenever such change is noticed by whoever is >>> controlling the inferior. >>> >>> My idea is to get the mechanism started by using the stop reply to >>> send a new notification, say, "arch-changed". >>> >>> That should trigger GDB to re-fetch the architecture data and >>> reinitialize it. >>> >>> In the particular case of SVE, we only need to fetch the target >>> description again, so we have the proper vector length and data types >>> set. >>> >>> Does this sound like a useful feature? Or should i go for the >>> solution with less impact that will only take care of re-fetching the >>> target description? >> >> I'm not keep on the idea of potential constant re-fetching of arch data. >> I'd think that "arch-changed=ARCH" with each arch having its own unique >> name (can be opaque to GDB) so that GDB can cache the arch description, >> and avoid refetching it over and over would be better. > > I don't like the re-fetching either, so i'm trying to minimize that. > > Part of the problem is that the vector length (VL) is per-thread, ... > >> >> Also, I don't think a state transition such a "arch changed" is the best. >> I'd think making the stop reply say: >> >>   "stopped on code running arch foo" >> >> is better. >> >> See this: >> >>   https://www.sourceware.org/gdb/papers/multi-arch/real-multi-arch/ >> >> In which Cagney suggested something very similar: >> >>   T00;...;Architecture=;... >>       The T packet is used to report the reason the target stopped to >> GDB. That packet includes information such as the processor and that >> processors registers. The packet can be extended to include the >> architecture of the processor that halted. >> > > ... so the above, even though it works nicely for reporting the stop of > a single thread, it won't carry information about potential other > threads that stopped along with the one the caused the stop reply to be > sent, right? We would need to fetch updates from the other threads in > case they changed their VL during execution. > >> >> Though for the SVE case, I'm not sure a target description change is the >> best model, where you end up with a different target description >> description >> for each potential different vector length. > > Right. A new target description comes along with new sizes for the > particular types and aggregates it defines. > >> >> An alternative could be for the target description to always describe the >> largest possible vector file, or explicitly describe the VLE registers >> as variable >> length, and then gdb would handle presenting the usable registers. >> GDB should >> be able to tell the size of the vector registers by looking at the VQ >> (or was >> it VL?  Or whatever it is called) register. > > The variable length description is technically more correct, but i think > we already opted for a different solution with multiple VL-based target > descriptions. > > My idea is to not rely on register values and, instead, focus on sizes > of some aggregates the target description defines. That way we are not > forced to fetch any registers and can infer the vector length from the > sizes on the new target description. > > Both native sides (GDB and gdbserver) and QEMU know how to detect VL > changes. It is just the communication of that change to GDB that we need > to sort out via RSP. > >> >> In effect, we can see the current native support as a middle ground, >> where aarch64_linux_nat_target::thread_architecture returns a different >> gdbarch, there's no target description re-fetching, I believe. >> > > There is no re-fetching in the sense that data doesn't get passed > around, but new target descriptions do get created dynamically > (aarch64_create_target_description) based on the new VL. The resulting > gdbarch then gets cached so we don't need to recreate that particular > variation. > > My idea for a RSP-based target description update tries to mimic that as > follows... > > - Remote end notices a target description / gdbarch change and notifies > GDB via a stop reply packet entry. > > - GDB fetches the stop reply data and knows it has to query the remote > about what particular threads had their target descriptions updated. I > think this needs to be a new packet, maybe a qXfer one with a different > object. The qXfer packet would handle large lists of threads (thinking > about future use cases, GPU's etc). > > - Remote sends a list of threads to GDB. > > - GDB fetches the list of threads it needs to re-fetch the target > descriptions from and proceeds to query the remote about those > descriptions. I think we could cache the descriptions here, or have an > opaque description that gets passed down to the target-specific code as > you suggested. > > - GDB finishes the update and caches (as much as possible) the gdbarch > per-thread/per-regcache. > > When no target description change has taken place we have nothing to do > and no RSP overhead, so it wouldn't slow things down. > > Does the above sound like an acceptable way forward? > > Luis >