[Bug 1001524] Cortex-M: Remote 'g' packet reply is too long

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001524

--- Comment #10 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-11 17:21:40 GMT ---
(In reply to comment #9)
> In Cortex-M architecture HAL there are files cortexm_stub.c and cortexm_stun.h.
> I assume that they provide support to GDB. There are structures with members
> that correspond to FPA registers - i guess due to state of matter at moment of
> eCos initial port to Cortex-M3. At present the Cortex-M floating point
> architecture is defined and implemented in silicon, at least for Cortex-M4F,
> and it is VFP. I realize that we have to replace FPA with VFP in cortexm_stup.*
> structures and code.

Correct. However for a while, to support older GDBs, we will have to return
fake FPA registers (even though they don't really exist). So we have to _add_
VFP support and use it exclusively for those Cortex-M's which have it; but for
everything else, we have to retain and use this "fake FPA". For now anyway.
Later on once newer tools are well established, we flip the switch and make the
default be to drop the fake FPA registers.

> Another issue is the thread context that needs to (also) keep VFP registers
> when available and in use. This is what I am starting to work on. In my view
> GDB stub and thread context as jobs do have common points and it would be good
> to synchronize them.

You would be well advised to look at other architectural HALs which have
hardware FPU support and see what they do, especially our i386 HAL. Lazy FPU
context switching is a practical necessity.

It's only possible to synchronise GDB stub and HAL saved thread context if that
is straightforward. One thing which should *not* happen is to make any changes
which increase the context switch time in order to make the layout match the
GDB register layout (which, of course, is not in our power to change). Real
performance should not be compromised because of the requirements of a
debugger.

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.