This is the mail archive of the
mailing list for the eCos project.
[Bug 1001524] Cortex-M: Remote 'g' packet reply is too long
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-bugs at ecos dot sourceware dot org
- Date: Sun, 1 Apr 2012 12:35:48 +0100
- Subject: [Bug 1001524] Cortex-M: Remote 'g' packet reply is too long
- Auto-submitted: auto-generated
- References: <firstname.lastname@example.org/>
Please do not reply to this email. Use the web interface provided at:
--- Comment #12 from Ilija Kocho <email@example.com> 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.
> > with following issues:
> > 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/:
> > 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.
> > 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
> 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 on the CC list for the bug.