Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Jonathan Larmour <jifl@eCosCentric.com>
Cc: gdb-patches@sourceware.org, Ilija Kocho <ilijak@siva.com.mk>,
	       Terry Guo <terry.guo@arm.com>,
	Pedro Alves <palves@redhat.com>
Subject: Re: [patch] Add support for VFP d16 layout  for Cortex-M4
Date: Fri, 20 Apr 2012 12:43:00 -0000	[thread overview]
Message-ID: <4F91593B.4020309@redhat.com> (raw)
In-Reply-To: <4F902B4E.9070704@eCosCentric.com>

On 04/19/2012 04:12 PM, Jonathan Larmour wrote:

> As mentioned in my response to the GDB list mail
> <http://sourceware.org/ml/gdb/2012-04/msg00149.html>, I have a patch to
> allow easy automatic use of Cortex-M targets with a register layout with
> 16 double precision / 32 single precision regs. This is as used in the
> increasingly popular Cortex-M4 core.
> 
> I have chosen to use the remote packet guessing approach again, rather
> than inferring from the executable's ELF header, because not everyone will
> actually want to use hardware FP just because they're using that core, so
> what the stub actually supports is a better indicator of what is wanted.


I'd like to make it clear that the guesses mechanism is a just a fallback
mechanism, useful when its too late to change the stubs out there to
send the xml description to gdb themselves.  It's not the ideal way forward,
and it can't scale beyond a few guesses.  The right thing is for
the stubs themselves to report the xml descriptions to GDB (with qXfer:features:read),
not to have them depend on GDB being able to guess it.

Cortex-M4 stubs can already send a xml description equivalent to this new
description to gdb today (without this patch), and things will work equally well,
since the xml description can be (as yours is) simply built using the
org.gnu.gdb.arm.m-profile and org.gnu.gdb.arm.vfp standard description
features.

Is it too late change the stubs that triggered this need to have them
send a xml description?  Despite this patch going in, that's the right
right to do.

That said, I'm no ARM expert, but I don't see anything wrong with the patch.
And having the xml file in the tree that stubs can copy freely is always good.

> +/* Say how long VFP double precision registers are. Used for documentation
                                                      ^
Double space after full stop, please.

> +   purposes and code readability.  These are fixed at 64 bits. */
                                                                 ^
Ditto.

-- 
Pedro Alves


  parent reply	other threads:[~2012-04-20 12:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-19 15:13 Jonathan Larmour
2012-04-19 15:58 ` Terry Guo
2012-04-19 16:09   ` Jonathan Larmour
2012-04-19 16:38     ` Terry Guo
2012-04-19 17:30       ` Jonathan Larmour
2012-04-20  7:51     ` Ilija Kocho
2012-04-20  8:31       ` Terry Guo
2012-04-20  8:54         ` Ilija Kocho
2012-04-20 11:44 ` Pedro Alves
2012-04-20 12:43 ` Pedro Alves [this message]
2012-04-20 13:20   ` Terry Guo
2012-04-20 13:22     ` Pedro Alves
2012-04-24  2:49   ` Jonathan Larmour
2012-04-26 20:28     ` Tom Tromey
2012-04-26 23:40       ` Jonathan Larmour
2012-04-27 15:55         ` Tom Tromey
2012-04-26  7:35 ` Sergio Durigan Junior
2012-04-26 15:07   ` Jonathan Larmour
2012-04-26 15:20     ` Pedro Alves
2012-04-26 15:29       ` Jonathan Larmour

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=4F91593B.4020309@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=ilijak@siva.com.mk \
    --cc=jifl@eCosCentric.com \
    --cc=terry.guo@arm.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