From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53092 invoked by alias); 11 Nov 2016 12:29:06 -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 53079 invoked by uid 89); 11 Nov 2016 12:29:05 -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=H*r:AES128-SHA, dating, transferred, transfer X-HELO: mail-wm0-f65.google.com Received: from mail-wm0-f65.google.com (HELO mail-wm0-f65.google.com) (74.125.82.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 11 Nov 2016 12:28:55 +0000 Received: by mail-wm0-f65.google.com with SMTP id m203so7484339wma.3 for ; Fri, 11 Nov 2016 04:28:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=h1CpN/hhPvFUAsyAYrk2dHR8YSbQInhzQbWZja47kOc=; b=T3zCmyYYWLTWR29TvZeqPGMjyh/fyXjdEKrMVvdasC1Ch3qhWvRBi6Xja349PU+OD4 tdYYc0F1Jp5VpRK0oFZy95PmDWVceXZJQyzdcibyVrkJeuhoVpoCClnsNIts51EaMIOI 9AI2GzCFcjmzQ0EX9MuQkrVtj2DuKm0zmyGcTbE+k0CvasJbI/JVLaBU0f4l7AXK4Fyc r3b5Biwh/tigVxo8CYm7N/vaRNJiDfxBhygqbRegV2vsFfm5K2vlHwWf4jAsxxJVegc8 31DwtOya0SDSIyzqKJywx1+APElzKhje62r3Hgrye/eWgYtBToHBbr+rwerBiJ1aTEPb 0qQg== X-Gm-Message-State: ABUngvdQz7z2yYbCoYndIJPrhDgSLqUPb/pELz0VW6uSIBcy0RnYeoo1Dtc4fV6rzxiCkw== X-Received: by 10.28.210.1 with SMTP id j1mr11738113wmg.86.1478867333209; Fri, 11 Nov 2016 04:28:53 -0800 (PST) Received: from E107787-LIN (gcc114.osuosl.org. [140.211.9.72]) by smtp.gmail.com with ESMTPSA id h2sm11179742wjy.40.2016.11.11.04.28.49 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 11 Nov 2016 04:28:52 -0800 (PST) Date: Fri, 11 Nov 2016 12:29:00 -0000 From: Yao Qi To: "Maciej W. Rozycki" Cc: Bhushan Attarde , "gdb-patches@sourceware.org" , Matthew Fortune , James Hogan , Andrew Bennett , Jaydeep Patil Subject: Re: [PATCH 01/24] MIPS: Handle run-time reconfigurable FPR size Message-ID: <20161111122844.GB31376@E107787-LIN> References: <1467038991-6600-1-git-send-email-bhushan.attarde@imgtec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00290.txt.bz2 On Thu, Nov 10, 2016 at 12:42:53PM +0000, Maciej W. Rozycki wrote: > > > > This is implemented by retaining the raw register size for the FPRs at its > > > native size (64-bits; this is required for remote packet offsets to work > > > 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 protocol > > if FPRs are 32-bit. > > Nope. In the FR=0 mode existing XML-described stubs present a file of 32 > 32-bit FPRs; this applies to MIPS32 targets only as so far we've had an > assumption that MIPS32 <=> FR=0 and MIPS64 <=> FR=1. I think switching > the view at this time would be an undesireable complication, as it would > be yet another variant we'd have to handle forever along with the new one. Yeah, there are different variants. Let me be specific, with this patch applied, on MIPS64, FR=0, how many bits needed for each FPR in 'g' packet? I ask this question for this sentence "This is implemented by retaining the raw register size for the FPRs at its native size (64-bits; this is required for remote packet offsets to work out correctly) and then truncating the cooked register size or not as required." in Bhushan's mail. IIUC, with this patch applied, on MIPS64, FR=0, FPR is 32-bit, but 64-bit space is used in 'g' packet. No? > > FWIW I think the FR=0 mode should have been chosen to present the FPR > file as 16 64-bit FPRs instead, with the cooked register view used to > access register halves if required, but then I think a further > complication would arise with non-XML-described stubs. > > > > The change also supports both XML and non-XML targets, but currently > > > bare-iron targets for which this update has any significant meaning do 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. > > I do hope the last patch which adds `gdbserver' features en masse, which > I didn't get to to looking through yet, has it (although I think the > individual features should be included along with corresponding base > target and native support instead). Oh, it must be this patch https://sourceware.org/ml/gdb-patches/2016-06/msg00511.html > > > "reconfigure FPRs" is a target description change to me, instead of a > > regcache change. > > The regcache change is partly historic, because parts of the series > (dating back to 2005) were implemented even before we had XML > descriptions, and an FR transition is also supposed to work with > non-XML-described MIPS64 bare-metal targets (where the FPR file is > presented as 32 64-bit FPRs regardless of the FR setting). I do agree a > target description should take precedence where available, and certainly > with Linux targets where you cannot get a MIPS64 FR=0 configuration or a > non-XML-described MIPS32 FR=1 configuration). > > What do you propose if we don't have a target description though? We > can't handle MIPS32 FR=1, because stubs won't transfer the upper halves of > FPRs, but we can handle MIPS64 FR=0, because we can simply ignore the > irrelevant upper halves. Why stubs doesn't transfer the upper bits of PFRs in case of MIPS32 FR=1? because of keeping backward compatibility? Does register_remote_g_packet_guess help? > > > 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. > > I think I'd prefer this to be the $fp_mode register if available (as > it'll include the FRE setting as well), and the $status register > otherwise. Linux kernels which support the FRE setting will always make > $fp_mode available, as it'll be a part of the same change (unless someone > sneaks a broken patch through behind my back, as I still yet have to see > the kernel parts of this framework, let alone review them). If we have $fp_mode, that is better. > > The rest looks like a good plan to me, although I think I like your #1 > proposal a bit better. > Thanks for your feedback, Maciej. I personally like #1 better too :) -- Yao (齐尧)