This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 01/24] MIPS: Handle run-time reconfigurable FPR size
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Bhushan Attarde <bhushan dot attarde at imgtec dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Maciej dot Rozycki at imgtec dot com, Matthew dot Fortune at imgtec dot com, James dot Hogan at imgtec dot com, Andrew dot Bennett at imgtec dot com, Jaydeep dot Patil at imgtec dot com
- Date: Tue, 8 Nov 2016 19:46:17 +0000
- Subject: Re: [PATCH 01/24] MIPS: Handle run-time reconfigurable FPR size
- Authentication-results: sourceware.org; auth=none
- References: <1467038991-6600-1-git-send-email-bhushan.attarde@imgtec.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 (齐尧)