From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51798 invoked by alias); 22 Jan 2020 14:56:33 -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 51790 invoked by uid 89); 22 Jan 2020 14:56:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=ground, whoever X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Jan 2020 14:56:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579704989; 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=lO4d1hNCucgFp4jp7DAFdzG9/TUqjGrd/d74Uxp8NLw=; b=TmXJ2cBU7rJiBJxOTbr0is/fGleZ8jOhn0D/zNqJCYrGFh8fdMSwhQxoLq+fzYK6I5FdMJ RghT0r2iubDNCRa8FYsVobZeNLlbYuttHzy9iSm5T3+zyIs9LTbDhf55VX0/4Ke3il7lyS JR14ss/ALNYPjMfgSq+wPq8WIUD5wBI= 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-364-3x_tJcSqNsmP2VbjGvXuTA-1; Wed, 22 Jan 2020 09:56:28 -0500 Received: by mail-wr1-f71.google.com with SMTP id z14so3215390wrs.4 for ; Wed, 22 Jan 2020 06:56:28 -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 q11sm58009784wrp.24.2020.01.22.06.56.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Jan 2020 06:56:25 -0800 (PST) Subject: Re: [RFC] Changing gdbarch mid-execution To: Luis Machado , "gdb@sourceware.org" References: <4f30e9b5-d196-1dc5-7713-6c42e7d9494d@linaro.org> From: Pedro Alves Message-ID: <69c1ca6c-d4d5-9d04-1115-3c9bdda3139f@redhat.com> Date: Wed, 22 Jan 2020 14:56: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: <4f30e9b5-d196-1dc5-7713-6c42e7d9494d@linaro.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-01/txt/msg00038.txt.bz2 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. 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. 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. 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. 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. Thanks, Pedro Alves