RE: [patch] Add support for VFP d16 layout for Cortex-M4

["Terry Guo" <terry.guo@arm.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