public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: Pedro Alves <palves@redhat.com>
Cc: Yao Qi <yao@codesourcery.com>, <gdb-patches@sourceware.org>
Subject: Re: [PATCH] MIPS: Handle the DSP registers for bare metal
Date: Tue, 30 Dec 2014 12:11:00 -0000	[thread overview]
Message-ID: <alpine.DEB.1.10.1412301141560.19155@tp.orcam.me.uk> (raw)
In-Reply-To: <54A27A7E.4070200@redhat.com>

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.

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

 So some other way has to be invented if you think the current working 
solution is not good enough for some reason.

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

  Maciej

  reply	other threads:[~2014-12-30 12:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-18 13:26 Yao Qi
2014-12-18 17:28 ` Pedro Alves
2014-12-19  3:55   ` Yao Qi
2014-12-19 11:18     ` Pedro Alves
2014-12-19 13:22       ` Yao Qi
2014-12-19 15:07         ` Pedro Alves
2014-12-30  1:15       ` Maciej W. Rozycki
2014-12-30 10:12         ` Pedro Alves
2014-12-30 12:11           ` Maciej W. Rozycki [this message]
2015-01-05 11:40             ` Pedro Alves
2015-01-07 15:11               ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.1.10.1412301141560.19155@tp.orcam.me.uk \
    --to=macro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=yao@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).