From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106738 invoked by alias); 8 Nov 2016 19:46:30 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 106723 invoked by uid 89); 8 Nov 2016 19:46:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=retaining, respective, halves, sve X-HELO: mail-qt0-f177.google.com Received: from mail-qt0-f177.google.com (HELO mail-qt0-f177.google.com) (209.85.216.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 Nov 2016 19:46:20 +0000 Received: by mail-qt0-f177.google.com with SMTP id n6so114243996qtd.1 for ; Tue, 08 Nov 2016 11:46:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SEDEMWTh8fS/FIcPWhANzIcGS4e6faiqPVVE64QWN7o=; b=YiH8+IRUnsnFzm5HRMtgALy+uIEYBDs1oE5ID3g1dxLZOJKR273vGXnmofm+ywYWpJ qpx7qz4Jd+duNMNTzxBu8nI0aRbrhsyNYN+m8mamQBmVpb9IuavUOJ0fXW56RfAzPhyn R07i+pauUA9m+15taZBxd1GqNT0F8ubjHSTgjfzuXP+5RsZP0JaB9B3cvHX4T7VKgx5x 0WAE7wCyFRLnCP1+XYLLddDcbdqgtCPBmxPPiXO7FjJEKF8JKN8SJmw1OElFCHsxBgKh xw2p1kOiCsQrXGJnUN73tWq2Kaz6jJYZ5RTs5usTKcTa8Y7TgGUDmO3lQO20IzGy9KRP iVLg== X-Gm-Message-State: ABUngvfO0l9EbJDy2q+TAN1oVCEvG+2q+XlEFZ3elqwzfo/9/+C7V5yJu1oSPFPHXfT/a/BCDHNjGKLxzsaIwA== X-Received: by 10.237.53.119 with SMTP id b52mr15335736qte.74.1478634378297; Tue, 08 Nov 2016 11:46:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.149.55 with HTTP; Tue, 8 Nov 2016 11:46:17 -0800 (PST) In-Reply-To: <1467038991-6600-1-git-send-email-bhushan.attarde@imgtec.com> References: <1467038991-6600-1-git-send-email-bhushan.attarde@imgtec.com> From: Yao Qi Date: Tue, 08 Nov 2016 19:46:00 -0000 Message-ID: Subject: Re: [PATCH 01/24] MIPS: Handle run-time reconfigurable FPR size To: Bhushan Attarde Cc: "gdb-patches@sourceware.org" , Maciej.Rozycki@imgtec.com, Matthew.Fortune@imgtec.com, James.Hogan@imgtec.com, Andrew.Bennett@imgtec.com, Jaydeep.Patil@imgtec.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00187.txt.bz2 Hi Bhushan, On Mon, Jun 27, 2016 at 3:49 PM, Bhushan Attarde wrote: > Many MIPS architecture processors can reconfigure the size of their > floating-point registers at the run time. The file comprising 32 > registers can be either 32-bit or 64-bit wide depending on whether CP0 > Status register's bit FR is zero or one, respectively. Fortunately a= ccess > to Status is available on all targets. > > Here's a change to handle this property. It requires the generic reg= ister > access code to raise the target backend's attention whenever a new > register set has been retrieved so that it can examine the state of > CP0.Status.FR and act accordingly. I have added this hook to > get_thread_regcache, the backend has then an opportunity to switch gd= barch > as necessary and let the caller know if it did so. If that indeed > happened, then the register cache originally retrieved is then discar= ded > and another one obtained using the newly-selected gdbarch. This new > register cache is not revalidated. > > > This is implemented by retaining the raw register size for the FPRs a= t its > native size (64-bits; this is required for remote packet offsets to w= ork > out correctly) and then truncating the cooked register size or not as > required. I have skipped `maintenance print registers' dumps here for > brevity, the types flip between "double" and "float" as expected. > If I understand you correctly, 64-bits are still transferred in remote prot= ocol if FPRs are 32-bit. > This change supports bare-iron, Linux and IRIX targets. For Linux a= nd > IRIX the width of the floating-point registers is set by the ABI of t= he > program being run by the OS kernel and the kernel is responsible for > setting CP0.Status.FR correctly; the image of Status accessible via > ptrace(2) is read-only. Therefore the respective backends mark the w= idth > as fixed and cause the run-time check to be skipped for efficiency. I > have verified that the Linux target does that correctly; the change f= or > IRIX is the same and is expected to be all right, but I have no acces= s to > such a system (I will appreciate anyone verifying that). > > The change currently supports 64-bit processors only as GDB has no w= ay to > access upper halves of floating-point registers on 32-bit processors = that > have a 64-bit FPU (i.e. MIPS32r2 and newer processors); this is menti= oned > in the explanatory notes included with the change itself. > > The change also supports both XML and non-XML targets, but currently > bare-iron targets for which this update has any significant meaning d= o not > really support XML. Any XML target is supposed to always provide an = FPU > description that matches the current setting of CP0.Status.FR, the new > code verifies this is always the case and rejects the description as > invalid otherwise. How do I understand "Any XML target is supposed to always provide an FPU description that matches the current setting of CP0.Status.FR"? I don't see how it is done in current GDB/GDBserver. "reconfigure FPRs" is a target description change to me, instead of a regcache change. I'd like GDB can deal with "target description of process is changed in runtime" in general, because this requirement exists in other places as well, - x86 kernel booting, the arch is 16-bit at the beginning, and switch to 32-bit or 64-bit later, https://sourceware.org/ml/gdb/2016-11/msg00003.html - ARM SVE vector registers length can be changed, There are two different ways to support handling target description change in general. Other thoughts are welcome too. 1) - Implement target hook to_thread_architecture in ARCH-linux-nat.c, in which we can use ptrace to read the register A which indicates the target description is changed or not. In MIPS, register A is CP0.Status. Create target info and return the right gdbarch. [In MIPS, we have one gdbarch for 32-bit FPR and one gdbarch for 64-bit FPR] - Add register A to expedited registers, which is included in the stop reply from GDBserver. - Add new gdbarch method target_description_changed_p, and its parameter is a vector of expedited registers got in remote.c:process_stop_reply. In default, it returns false. In MIPS, we can tell whether target description is changed by the value of and current gdbarch. - In remote.c:process_stop_reply, if gdbarch_target_description_changed_p returns true, invalidate all regcaches, request target description from gdbserver again, and get the updated target description. 2) - Add enum TARGET_WAITKIND_ARCH_CHANGED, - In ARCH-linux-nat.c, interpret/override linux_nat_wait. If linux_nat_wait returns, and there is a real event of stop, call ptrace to get the register A value, if it is different from what we remember in current gdbarch, mark the event pending and return TARGET_WAITKIND_ARCH_CHANGED, - In remote, add a new stop reply, T00arch, for example, https://sourceware.org/gdb/onlinedocs/gdb/Stop-Reply-Packets.html If remote.c:process_stop_reply sees T00arch, return TARGET_WAITKIND_ARCH_CHANGED. - In gdb core, if TARGET_WAITKIND_ARCH_CHANGED is reported by target_wait, call target_find_description, to update target description. - In gdbserver, add target method target_stopped_by_changed_arch, and use it in remote-utils.c:prepare_resume_reply. Get register A value by ptrace too, and return true if it is different from the knowledge in process_info.tdesc. --=20 Yao (=E9=BD=90=E5=B0=A7)