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

[Jonathan Larmour <jifl at eCosCentric dot com>]

On 20/04/12 13:40, Pedro Alves wrote:
> 
> 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.

I don't think that's unreasonable for a principle, but as I mentioned
elsewhere, some of these targets are very resource constrained. Bytes
really do count. I know it's not ideal, but on the other hand I hope that
there aren't going to be that many layouts to support, and this argument
only really applies to the processors which tend to be very
resource-limited, not big x86 or PowerPC chips.

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

Sorry it's taken me a few days to get back to you, but I've been
implementing what's required to send the XML target description support in
the eCos stub, so that I could have hard data. Unfortunately it has
confirmed my suspicions. Adding code and const data to send back the
description for a vanilla Cortex-M profile target has added 1252 bytes to
our GDB stub's footprint. If the VFP regs description is added to that,
that adds another 931 bytes to give 2183 bytes. That's a big penalty.

XML is not exactly concise. Theoretically we could try and create some
sort of encoding to programmatically generate the XML instead on a dynamic
basis, but that's quite a complex thing to be forced to do, and not
scalable. Unfortunately, in retrospect I'm not sure XML was really the
best format for sending important information from stub to host.

It might save a bit if it were possible for a stub to include XML files
located on the debugging host, but GDB currently assumes any referenced
inclusions must only be read from the target with another qXfer. Maybe the
current feature XML files could be installed by GDB somewhere central, and
be able to be looked up according to some path setting. But even if this
is a good idea, obviously it's only theoretical now. I'm not sure it would
save enough, but it would help.

I understand that for host gdbservers and beefy targets, sending target
descriptions is easy and a good thing; but we can't lose sight of the fact
that many modern System-on-Chips are not like that, and Cortex-M targets
fall into that category. I wouldn't expect to put a GDB stub on the
smallest Cortex-M I've seen with only 16K flash and 4K RAM, but once
you're talking about 64K, it may become more feasible, and little changes
make a big difference.

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

I'll fix those.

How would you like to move forward?

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine