[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 #9 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-11 13:06:41 GMT ---
(In reply to comment #8)
> (In reply to comment #7)
> > I am working on Cortex-M4 architectural FPU support. Having VFP registers in
> > GDB would be of great help, so propose that we synchronize our work and get VFP
> > support to Cortex-M stub.
> 
> No need. The changes here should only affect those processors without FPU
> support.
> 
> If the program has been built with VFP registers, then an ELF attribute gets
> set in the executable marking it as such. This makes GDB treat it differently
> to the situation described in this bugzilla bug.
> 
> Or at least, that's what's meant to happen. If it doesn't, GDB'll want to be
> fixed until it does.

Hi Jifl

Here's my rationale (though I'm not initiated in GDB stuff so it may be
incomplete).
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.

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.

Comments appreciated.
Ilija

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