This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [patch] Add support for VFP d16 layout for Cortex-M4
- From: "Terry Guo" <terry dot guo at arm dot com>
- To: "'Pedro Alves'" <palves at redhat dot com>, "Jonathan Larmour" <jifl at eCosCentric dot com>
- Cc: <gdb-patches at sourceware dot org>, "Ilija Kocho" <ilijak at siva dot com dot mk>
- Date: Fri, 20 Apr 2012 21:16:02 +0800
- Subject: RE: [patch] Add support for VFP d16 layout for Cortex-M4
- References: <4F902B4E.9070704@eCosCentric.com> <4F91593B.4020309@redhat.com>
Hi Pedro,
> -----Original Message-----
> From: Pedro Alves [mailto:palves@redhat.com]
> Sent: Friday, April 20, 2012 8:40 PM
> To: Jonathan Larmour
> Cc: gdb-patches@sourceware.org; Ilija Kocho; Terry Guo; Pedro Alves
> Subject: Re: [patch] Add support for VFP d16 layout for Cortex-M4
>
> 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.
>
Ideally using the qXfer:features:read is the most natural way. Can you
confirm that once it is used, the guess mechanism won't be resorted for M4?
The code in trunk already has two guess methods for Cortex-M. I don't want
things get messed up.
Another thing in my mind is as Jonathan said before, the stub that will be
programmed into flash is sensitive to the bytes. So I guess they may tend to
save bytes by not returning target.xml. I am not sure what I am assuming is
true. Please correct me if I am wrong.
BR,
Terry