[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 #12 from Ilija Kocho <ilijak@siva.com.mk> 2012-04-01 12:35:40 BST ---
(In reply to comment #11)
> (In reply to comment #42 of bug #1001468)
> > Now I have enough Cortex-M4F architectural support to do some GDB testing. I
> > have applied the attachment (id=1648) [details] and it seems to work
> 
> Yay. And indeed there's the s0-s31 registers as expected.

Indeed.

> 
> > with following issues:
> 
> Boo.
> 
> > 1. Remote 'g' packet reply is too long
> > 
> > If I connect to gdb server (RedBoot on Cortex-M4F) prior to submit the elf file
> > I get the error /Remote 'g' packet reply is too long/:
> [snip]
> 
> > This is probably not a problem when using gdb from command line, but it is with
> > Eclipse.
> 
> So you find that Eclipse connects via GDB before providing a file to GDB? That
> seems wrong to me, for exactly the reason we need it not to. What's more, I
> believe with at least our (eCosCentric's) eclipse, it behaves what I consider
> the correct way and doesn't connect until asked to by which point it has the
> file to debug. But I don't think we did anything special to do it in that
> order. So are you sure this is Eclipse's behaviour? 

Well my statement was little bit too general. It's actually "C/C++GDB Hardware
Debugging" plugin that comes bundled with (some configurations of) Eclipse CDT.
When I tried to debug with Eclipse I got /Remote 'g' packet reply is too long:/
and this was the best explanation.

Now I got old good Zylin plugin, where I can manually set commands, and it
works for me (and confirms my doubt about the other one).

What matters, it's a non-issue for your GDB patch.

[snip]

> 
> > 2. Potential eCos/RedBoot issues
> > 
> > Since register numbers are not consecutive there may be issue with some stub
> > eCos/Redboot functions: For instance stub_format_registers() requires
> > consecutive numbers.
> 
> I don't think I see a real problem there. cortex-M, like many HALs, provides
> its own get_register() in cortexm_stub.c. So you can just return 0s for >invalid

I guess you mean REGSIZE() macro. I was about to ask about that as it seemed as
a way, though inefficient one. Now have I tried and looks OK. I'm happy for the
time being.

> registers. Or arguably, an improvement might apparently be to define
> CYGHWR_REGISTER_VALIDITY_CHECKING in cortexm_stub.h and provide a
> get_register_valid() implementation. But that probably isn't worth the effort
> since either way the user should never see the result.

This would probably be even less efficient by wasting bandwidth for XXXes.

> 
> I presume you've already been making changes in this area anyway since you'll
> have needed to change target_register_t to an unsigned long long if there's an
> FPU (and stick with unsigned long if there isn't, I hope!).

I keep target_register_t cyg_uint32 with defined TARGET_HAS_LARGE_REGISTERS
It's still a development code but, now that we have STM 32F4 on board, I could
put it somewhere if it could speed up the development. (FYI - Lazy context
switching is implemented.)

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