From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11252 invoked by alias); 6 Jan 2020 14:08:08 -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 11244 invoked by uid 89); 6 Jan 2020 14:08:08 -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,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Spam-Relays-External:sk:mail-qt, H*r:sk:mail-qt, H*RU:sk:mail-qt, HX-HELO:sk:mail-qt X-HELO: mail-qt1-f181.google.com Received: from mail-qt1-f181.google.com (HELO mail-qt1-f181.google.com) (209.85.160.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 06 Jan 2020 14:08:06 +0000 Received: by mail-qt1-f181.google.com with SMTP id k40so42507650qtk.8 for ; Mon, 06 Jan 2020 06:08:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=Y/tMYOv6AbacGcMYEijb5c1rjyGmuzZJBWX7UW65yX8=; b=pbcD5JDECTW4LGTDWuuaRnX7eSwkdrzFw7ptBXsJFwizmbjQhWQcWogeH3T4y7QI/D 2jLJXhWC7dovmEGFSdnl/GJrbapEhH8nlMX8vTMGLiiTZ/rj/zLFaq68wZ+0D/ynvnF8 2yMh3YN5Fv1iwi/19Lv7tWhgLn2YA1usUjWB1GVuZndvNbLCbETNp3TtUA7PWmhWAsrS kDJx0AaCCx7486paFrxlEzrk5g+3tgCDs6ExU5OLL6J3Qe/ucTD5nUyLZ7aJ4QBoejf/ QlhP514F+RnjON6a5VClYaF5HncnPf+rlhbIMNVBpHWU/8A7IcJfYaseKl50rPDzyb9W znJQ== Return-Path: Received: from [192.168.0.185] ([191.249.237.235]) by smtp.gmail.com with ESMTPSA id q25sm20925137qkq.88.2020.01.06.06.08.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Jan 2020 06:08:03 -0800 (PST) From: Luis Machado Subject: [RFC] Changing gdbarch mid-execution To: "gdb@sourceware.org" Message-ID: <4f30e9b5-d196-1dc5-7713-6c42e7d9494d@linaro.org> Date: Mon, 06 Jan 2020 14:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00005.txt.bz2 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? Regards, Luis