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

[Jonathan Larmour <jifl@eCosCentric.com>]

On 26/04/12 20:35, Tom Tromey wrote:
>>>>>> "Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:
> 
> Jifl> Adding code
> Jifl> and const data to send back the description for a vanilla Cortex-M
> Jifl> profile target has added 1252 bytes to our GDB stub's
> Jifl> footprint. If the VFP regs description is added to that, that adds
> Jifl> another 931 bytes to give 2183 bytes. That's a big penalty.
> 
> Can the XML be compressed?
> I don't know.  If not, what if it could be?

I assume you mean having it in the stub in a pre-compressed form; in which
case yes, that helps[1]. If you meant compressing at runtime at the point of
sending, that would mean having to include something zlib-y in the program,
which would then add to footprint, which is why I was initially suggesting
some sort of encoding of the information required (not merely encoding the
XML) rather than just compression. That would be complex though.

But if GDB could handle compressed target descriptions, that would be useful.
Perhaps the stub could use a different $qSupported response to indicate its
compressed, or perhaps GDB could recognise magic numbers at the start of a
$qXfer:features:read response and pass to zlib. (e.g. gzip is always 0x1f,0x8b).

> I'm curious what you use for your stub.
> Based on the recent gdb@ threads, it seems like it can't be gdbserver.

There's a stub as part of eCos. It originally was used in Cygnus, but
according to its headers came from HP before that. Of course it's been hacked
on a lot in eCos so may be quite different to the original now.

Jifl
[1] Using an xml file defining just the main GPRs for Cortex-M as an example,
gzip -9 compresses that from 674 bytes to 237 bytes. Add in the VFP regs and
it goes from 1551 bytes to 330. Evidently the additional code overhead to deal
with parsing and handling sending the target description is about 600 bytes,
with Thumb-2 anyway.