This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] MIPS: Handle the DSP registers for bare metal
- From: Pedro Alves <palves at redhat dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: Yao Qi <yao at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Mon, 05 Jan 2015 11:39:58 +0000
- Subject: Re: [PATCH] MIPS: Handle the DSP registers for bare metal
- Authentication-results: sourceware.org; auth=none
- References: <1418909149-29929-1-git-send-email-yao at codesourcery dot com> <54930ED2 dot 1080806 at redhat dot com> <87r3vwqooq dot fsf at codesourcery dot com> <5494098B dot 7080002 at redhat dot com> <alpine dot DEB dot 1 dot 10 dot 1412300034430 dot 19155 at tp dot orcam dot me dot uk> <54A27A7E dot 4070200 at redhat dot com> <alpine dot DEB dot 1 dot 10 dot 1412301141560 dot 19155 at tp dot orcam dot me dot uk>
On 12/30/2014 12:10 PM, Maciej W. Rozycki wrote:
> On Tue, 30 Dec 2014, Pedro Alves wrote:
>
>>> > > I'm not sure offhand whether the piece of patch proposed you refer to
>>> > > here is correct or not, but the overall scope of this and the other patch
>>> > > Yao has mentioned yet outstanding is support for legacy bare-metal RSP
>>> > > stubs that have no notion of target descriptions and may even predate
>>> > > GDB's support for these descriptions, and yet they want to make all
>>> > > processor registers available for inspection and modification by GDB.
>>> > > This code comes from MIPS UK and dates back to early 2000s and I think it
>>> > > would be good having it upstream so that standard GDB can talk to these
>>> > > stubs. The fixed layout of the g/G packet and corresponding p/P packet
>>> > > offsets have been set by the bare-metal SDE toolchain years ago.
>> >
>> > The way to handle that is still through target descriptions -- if a
>> > target doesn't send a target description, GDB maps known layouts to built-in
>> > target descriptions. See mips_register_g_packet_guesses.
> Register probing Yao mentioned is still needed, because in this fixed
> packet format the whole set of architecturally defined register slots is
> exchanged with the RSP stub, e.g. 8 * 32 = 256 CP0 registers, 8 * 32 = 256
> CP2 registers, etc. (as documented by the change to mips-tdep.h proposed),
> even if some are not present, e.g. not all CP0 register slots have already
> been allocated in the architecture so far and the vast majority of them is
> optional.
That's orthogonal.
>
> The information on which registers are present and which are not will not
> be supplied by the target and has to be determined by gradual discovery,
> that is poking at registers as they are determined to be present, i.e.
> first CP0.PRId that is always there, then CP0.Config0 if present, then
> CP0.Config1 if present, and so on. Gaps will be present in the packets
> exchanged for the absent registers as with the ACX registers discussed
> previously.
>
> And if we were to define built-in target descriptions for the possible
> variants of present register sets, then, as noted by Yao, we hit the issue
> of having to make some 2^50 templates (slightly fewer actually, as there
That'd be silly of course, but it's also not what I meant. The built-in
description is used for the case of a legacy stubs that does not report a
target description, and those stubs you say use a fixed register layout.
So we're talking about _one_ built-in target description that describes
that fixed register layout.
> are some dependencies between the presence of some registers, e.g. you
> can't have a processor that has a CP0.Config2 register, but does not have
> CP0.Config1, the reverse is allowed; similarly a CPU can't have the ACX
> register when it does not have CP0.Config3) which is of course beyond
> technical capabilities as e.g. a 32-bit host will have fewer bytes of
> addressable memory even.
> NB `mips_register_g_packet_guesses' is not necessarily relevant here as
> there may be registers accessible through the stub via the p/P packets
> only and not included in the g/G packet layout for performance reasons
If existing/legacy stubs are doing that in practice, then we can
make gdb pick the fallback description (in case in target doesn't
provide one) depending on selected osabi.
> (the packet may be shorter than the maximum defined) as to transfer all
> the registers through a JTAG link every time the target is stopped may be
> exceedingly slow, especially when single-stepping.
For the single-stepping case, the fix should be to include
all the registers GDB needs to compute whether the step finished
directly in the expedite stop reply, though.
Thanks,
Pedro Alves