This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001524] Cortex-M: Remote 'g' packet reply is too long


Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001524

--- Comment #6 from Jonathan Larmour <jifl@ecoscentric.com> 2012-03-09 17:15:26 GMT ---
(In reply to comment #5)
> Hi Jifl
> 
> (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.

Sorry yes, I wasn't entirely clear here, even though I made this point in my
gdb-patches mail - by using this patch we can migrate in a more organised
manner, rather than having to use CDL to match stubs to tools. The CDL can go
in, defaulting to the present (longer) format, and a bit later on we can throw
the switch.

That was my intention at the time I wrote the patch, but then the issue got
forgotten about in GDB land which led me to forget the eCos side too.

> 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?

As above, no - it was my original intention. I even made a patch at some point
(can't find it now). But if the GDB patch isn't accepted, I suggest we patch
our own GDB this time round regardless. I'd rather the patch was accepted
though, particularly if they would prefer an alternative solution to the same
problem, or if they spot I've missed something. I greatly prefer we should stay
aligned to upstream GDB (or keep upstream GDB aligned to us ;-)), indeed
because of other tools like Codesourcery's.

It looks like I'll be merging my patch with one come up with independently by
Pedro Alves. He's a GDB maintainer too, so chances are high now that it will go
in.

> <aside>
> In the long term, we may also wish to support the Cortex-M4 VFP registers in
> the stub.
> </aside>

That's a given - not only would stubs returning VFP registers be newer stubs so
no backward compatibility problems, but they inherently have to use a
differently formatted 'g' register anyway.

Jifl

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]