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: Fri, 30 Mar 2012 16:54:02 +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 #11 from Jonathan Larmour <email@example.com> 2012-03-30 16:53:58 BST ---
(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) 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
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? If it didn't do it that way
with our eclipse, then we would also see problems when debugging normal (not
VFP) Cortex-M binaries, as that also uses the provided binary to work out what
to do, using the previous patch (the one I checked in to GDB recently).
> 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
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.
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!).
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.