From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63721 invoked by alias); 23 Jan 2020 16:06:56 -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 63712 invoked by uid 89); 23 Jan 2020 16:06:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,UNSUBSCRIBE_BODY autolearn=no version=3.3.1 spammy=H*f:sk:4f30e9b, H*f:sk:69c1ca6, HX-Languages-Length:6707 X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (207.211.31.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Jan 2020 16:06:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579795612; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2O4NWlkbCbwMe7+psmqdtL3ODLt1wffAQAallHpNZe8=; b=BYmxXimCrtK76bOWoXJANDPa7cFD452lpnbl69I4KcohS3e3GKCAVVOQjl6WM7Ymb1x78w WnIVWLk6QlXWczxTH6Qt8I1Ro7Cpgj+dfLZpAN8NQRgowOikPLu+SXcHChG/zZwLNx2Bir FaMfhn3XEoJ+aj02BcZQUwXzCPjV0HA= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-177-Ih75d6a1PWydaa5qyChNTA-1; Thu, 23 Jan 2020 11:06:46 -0500 Received: by mail-wr1-f71.google.com with SMTP id v17so1997247wrm.17 for ; Thu, 23 Jan 2020 08:06:46 -0800 (PST) Return-Path: Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id r62sm3661839wma.32.2020.01.23.08.06.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jan 2020 08:06:44 -0800 (PST) Subject: Re: [RFC] Changing gdbarch mid-execution To: Luis Machado , "gdb@sourceware.org" References: <4f30e9b5-d196-1dc5-7713-6c42e7d9494d@linaro.org> <69c1ca6c-d4d5-9d04-1115-3c9bdda3139f@redhat.com> <39da275d-ccac-4f47-b666-377f7e099da5@linaro.org> From: Pedro Alves Message-ID: <938f61f4-cfd4-98fa-d8d7-a561bc279ab9@redhat.com> Date: Thu, 23 Jan 2020 16:06:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <39da275d-ccac-4f47-b666-377f7e099da5@linaro.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2020-01/txt/msg00048.txt.bz2 On 1/22/20 5: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-execut= ion. This can be done at the thread level. >>> >>> Native GDB already supports this by looking at the ptrace data. But doi= ng this for a remote target requires changes to the RSP. >>> >>> Instead of changing things just for this particular case, i'm consideri= ng having a more general mechanism for updating the architecture data whene= ver 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 reinitial= ize it. >>> >>> In the particular case of SVE, we only need to fetch the target descrip= tion 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 descrip= tion? >> >> I'm not keep on the idea of potential constant re-fetching of arch data. >> I'd think that "arch-changed=3DARCH" 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. >=20 > I don't like the re-fetching either, so i'm trying to minimize that. >=20 > Part of the problem is that the vector length (VL) is per-thread, ... >=20 >> >> Also, I don't think a state transition such a "arch changed" is the best. >> I'd think making the stop reply say: >> >> =C2=A0 "stopped on code running arch foo" >> >> is better. >> >> See this: >> >> =C2=A0 https://www.sourceware.org/gdb/papers/multi-arch/real-multi-arch/ >> >> In which Cagney suggested something very similar: >> >> =C2=A0 T00;...;Architecture=3D;... >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The T packet is used to report the reason= the target stopped to GDB. That packet includes information such as the pr= ocessor and that processors registers. The packet can be extended to includ= e the architecture of the processor that halted. >> >=20 > ... 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 th= at 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. Yes, but we also need to fetch their registers anyway too. It's just another piece of information that we need to retrieve. Maybe we could include the "current architecture" info in the 'g' packet's reply. >=20 >> >> 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 descrip= tion >> for each potential different vector length. >=20 > Right. A new target description comes along with new sizes for the partic= ular types and aggregates it defines. >=20 >> >> An alternative could be for the target description to always describe the >> largest possible vector file, or explicitly describe the VLE registers a= s variable >> length, and then gdb would handle presenting the usable registers.=C2=A0= GDB should >> be able to tell the size of the vector registers by looking at the VQ (o= r was >> it VL?=C2=A0 Or whatever it is called) register. >=20 > The variable length description is technically more correct, but i think = we already opted for a different solution with multiple VL-based target des= criptions. We did? >=20 > 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 t= he new target description. >=20 > Both native sides (GDB and gdbserver) and QEMU know how to detect VL chan= ges. It is just the communication of that change to GDB that we need to sor= t out via RSP. I don't know about QEMU, but the native side communicates the vector length= with the kernel exactly via a register.. >=20 >> >> 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. >> >=20 > 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_tar= get_description) based on the new VL. The resulting gdbarch then gets cache= d so we don't need to recreate that particular variation. Which is still a lot more work than reporting "N" size, where N is a simple= number. Tdescs are de-dupped by hashing/comparing the whole tdesc xml text, for exa= mple. And how are you going to force a vector length change from GDB, if you go t= he tdesc route? With the register-like approach, you can just write to a regi= ster, or something like it with a known value. With the tdesc route, you can't, = it's read-only. Writes _must_ be considered, for inferior function calls, for example. That's one of the features of the current ptrace interface design, see: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/thread.h= tml#478941 http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/479843.h= tml >=20 > My idea for a RSP-based target description update tries to mimic that as = follows... >=20 > - Remote end notices a target description / gdbarch change and notifies G= DB via a stop reply packet entry. >=20 > - GDB fetches the stop reply data and knows it has to query the remote ab= out 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. T= he qXfer packet would handle large lists of threads (thinking about future = use cases, GPU's etc). >=20 > - Remote sends a list of threads to GDB. >=20 > - GDB fetches the list of threads it needs to re-fetch the target descrip= tions from and proceeds to query the remote about those descriptions. I thi= nk we could cache the descriptions here, or have an opaque description that= gets passed down to the target-specific code as you suggested. >=20 > - GDB finishes the update and caches (as much as possible) the gdbarch pe= r-thread/per-regcache. >=20 > When no target description change has taken place we have nothing to do a= nd no RSP overhead, so it wouldn't slow things down. >=20 > Does the above sound like an acceptable way forward? I'm afraid this doesn't consider the whole story. Thanks, Pedro Alves