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: unassigned at bugs dot ecos dot sourceware dot org
- Date: Mon, 2 Apr 2012 21:49:36 +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 #13 from Jonathan Larmour <email@example.com> 2012-04-02 21:49:32 BST ---
(In reply to comment #12)
> 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.
Okay. So just to be absolutely clear, do you think you have tested GDB enough
that I should go ahead and submit this patch to upstream GDB? Or should I wait
a bit longer?
> > > 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.
Actually I did mean get_register(), which here comes from cortexm_stub.c.
That's what stub_format_registers() calls (if !TARGET_HAS_LARGE_REGISTERS). My
idea was to simply check the register number. However, using
TARGET_HAS_LARGE_REGISTERS as you say you have done means in fact this is
> > 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.
Well, the bandwidth will be exactly the same, but this is irrelevant now.
> 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.)
Yes, using TARGET_HAS_LARGE_REGISTERS means not having to worry about
target_register_t's size. In fact I now see that's what's done elsewhere for
Feel free to put up the code, but it's not likely I'd be able to work on
adapting it for the F4 straight away - we're incredibly busy here at
eCosCentric at the moment. I may be able to visually run through the patch
though just to look for any potential problems.
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.