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: Pedro Alves <palves at redhat dot com>
- To: Terry Guo <terry dot guo at arm dot com>
- Cc: Jonathan Larmour <jifl at eCosCentric dot com>, gdb-patches at sourceware dot org, Ilija Kocho <ilijak at siva dot com dot mk>
- Date: Fri, 20 Apr 2012 14:20:00 +0100
- Subject: Re: [patch] Add support for VFP d16 layout for Cortex-M4
- References: <4F902B4E.9070704@eCosCentric.com> <4F91593B.4020309@redhat.com> <001501cd1ef7$bd79e490$386dadb0$@guo@arm.com>
Hi Terry,
On 04/20/2012 02:16 PM, Terry Guo wrote:
> From: Pedro Alves [mailto:palves@redhat.com]
>> 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.
Correct. If the target returns a xml description with qXfer:features:read,
the guess mechanism is never triggered.
>
> 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.
--
Pedro Alves