Re: [PATCH 01/24] MIPS: Handle run-time reconfigurable FPR size

[Yao Qi <qiyaoltc at gmail dot com>]

Hi Bhushan,

On Mon, Jun 27, 2016 at 3:49 PM, Bhushan Attarde
<bhushan.attarde@imgtec.com> 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 access
>     to Status is available on all targets.
>
>     Here's a change to handle this property.  It requires the generic register
>     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 gdbarch
>     as necessary and let the caller know if it did so.  If that indeed
>     happened, then the register cache originally retrieved is then discarded
>     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 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.

>      This change supports bare-iron, Linux and IRIX targets.  For Linux and
>     IRIX the width of the floating-point registers is set by the ABI of the
>     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 width
>     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 for
>     IRIX is the same and is expected to be all right, but I have no access to
>     such a system (I will appreciate anyone verifying that).
>
>      The change currently supports 64-bit processors only as GDB has no way 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 mentioned
>     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 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.

"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.

-- 
Yao (齐尧)