This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 19.04.2012 17:57, Jonathan Larmour wrote:
> On 19/04/12 16:45, Terry Guo wrote:
>> I support this patch and your idea that using g_packet_guess is
>> smarter and more flexible. I will try your patch out when I am at
>> office tomorrow. What kind of board and gdb stub are you using?
>> Currently I only have a STM32F4 board in hand but couldn't find a
>> suitable gdb stub to access its FPU registers. Such functionality in
>> OpenOCD is still in development. Do you have any recommendations on
>> gdb stub for M4 board?
> It is currently work in progress in eCos, but as yet uncommitted (far more
> info and history than you need to know is here:
> <http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001524>). Most
> development is taking place on a Freescale Kinetis board, primarily by
> Ilija Kocho, with me interfering along the way ;-). The eCos changes still
> need to be reviewed before they're committed.

The stubware is pretty much ready but I still have work with other parts
of Cortex-M4F FPU architectural support
I am currently on a trip, tomorrow I return and I will intensify the
work. I hope to have patches ready for Bugzilla till end of next week
but I can't promise.

Terry, I could provide you Internet access to a RedBoot target fitted
with the new stub. You will be able to connect with GDB and do some
tests. I could assist you by means of Skype.

> STM32F4 is likely to follow very soon after. 

Currently I am working with Kinetis K70, but support for STM32F4 should
work almost out of box, probably few CDL lines.

> Ironically, it's not likely
> to be committed until we have some confidence that what goes into GDB will
> match up with what the stub is doing! We wouldn't want to commit something
> that has to change in an incompatible way.

Indeed, it would be better if this question is resolved in GDB sooner
rather than later, than GDB will set standard that all stubs will have
to follow.

Ilija


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]