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: Fri, 9 Mar 2012 09:18:22 +0000
- 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 #5 from John Dallaway <email@example.com> 2012-03-09 09:18:19 GMT ---
(In reply to comment #3)
> A CDL option approach isn't ideal. You should not have to match programmed
> stubs to particular versions of tools. You can't use certain boards with
> particular stub versions with certain versions of GDB. Stubs are meant to be
> persistent and long-lived and independent of toolchain versions.
I agree. However, reducing the length of the 'g' packet reply is a good thing
in the long term. Especially when debugging multi-threaded code using an IDE
over a slow serial connection. IDEs tend to fetch the register sets for all
threads when single stepping.
> I would prefer to fix GDB, hence this:
> (and you can see the rest of the thread for more rationale).
> However it looks like the discussion died off and I didn't chase it up. I will
> do so now.
> There's nothing to stop an updated version of my patch going into the tools
> being respun though - my GDB contributions are covered by an FSF assignment.
I hope your patch is accepted.
I still think we should move with the times and have a CDL option to support
the new 'g' packet reply length in the Cortex-M stub. This would be mainly for
performance reasons, but also to support builds of GDB 7.3 and 7.4 without your
patch (eg CodeSourcery tools). The option could default to the original
behaviour, at least initially. We could change the default to the new behaviour
when most people have moved to GDB 7.3 or later. People who must stick with GDB
6.8.50.x in the long term should be able to use a target description file.
Do you see any issues with this dual approach?
In the long term, we may also wish to support the Cortex-M4 VFP registers in
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.