[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Writing a CDT debugger for a none GDB target.
|
Looking at the amount of processors support in GDB, the amount of proprietary GDB stubs (you don't have to put GPL on the target), the pervasive use in embedded and Linux systems, etc., it is hard not to come to the conclusion that GDB is the de-facto debugger.
Regarding the advantages I see a lot of features for multicore and multisystem, e.g. with one GDB instance you can debug multiple cores/processes at the same time _even_ if they have a different architecture! Offloading to the host is sometimes nice but when you have many cores, the communication between the host and the target quickly becomes the bottleneck, this is why many improvements such as conditional expression in breakpoint and tracepoint can be evaluated directly on the target when appropriate.
Regarding tracing, GDB and LTTng are both aligning on the common trace format, GDB tracepoint got quite an uplift in recent years (http://sourceware.org/gdb/current/onlinedocs/gdb/Tracepoints.html#Tracepoints), OS awareness is already in CDT/DSF/GDB (http://wiki.eclipse.org/CDT/MultiCoreDebugWorkingGroup/OSAwareness) and the amount of GDB improvements is hard to keep up with, python scripting, logging, etc, just reading the new features in the GDB patch mailing list is quite something http://sourceware.org/ml/gdb-patches.
My favorite new feature is the dynamic printf: http://sourceware.org/gdb/current/onlinedocs/gdb/Dynamic-Printf.html#Dynamic-Printf where you can even see the output directly in the console if you want to.
In addition many companies have GDB improvement projects, one of them is the remote protocol: https://sites.google.com/site/mcatiwg/services-framework-specification/2-high-level-design.
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
Sent: November-13-12 10:53 AM
To: CDT General developers list.
Cc: TCF Development (tcf-dev@xxxxxxxxxxx)
Subject: Re: [cdt-dev] Writing a CDT debugger for a none GDB target.
Hi Steve,
(cross-posting to tcf-dev),
The TCF debugger is very much alive without EDC - in fact Wind River is going to GA its first product based on the TCF debugger very soon. And I know about other companies who are also working on products based on the TCF debugger. Initial data indicates that significant single-stepping performance gain can be achieved by replacing gdb with TCF, thanks to the fully asynchronous nature of TCF.
It's not true that your target has to run the full 54,000 LOC agent to leverage the debugger. In fact, the modular structure of TCF is one of its biggest advantages compared to gdb - you can offload the full symbol resolution step to the host while still speaking the TCF protocol across the communication chain. Another possibility is running an even smaller agent on the target - could even be gdbserver - and have the entire TCF debugger run on the host, communicating with that small agent.
Roughly speaking, I'd say that advantages of gdb include
- VERY established code base, commandline scripting, lots of existing architecture ports to derive from
Advantages of TCF include
- Very clean, modular code base optimized for deterministic high performance on multicore/multi-system even with high latencies
- Supports completely new kinds of tools by re-using modular building blocks (eg tracing, OS Awareness, ...)
- EDL license (BSD-like) avoids GPL on the target
Which of both options is more appropriate depends a lot on your needs.
I'll be happy to give more information when you are interested in TCF.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect - Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Steve Jones
Sent: Tuesday, November 13, 2012 10:19 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Writing a CDT debugger for a none GDB target.
Hi,
I've been reading up on the Eclipse/CDT debugger interface for several days to try and get some insight on how I might develop code to support a 16-bit processor that is not supported by the GDB debugger.
I can see a CDT debugger development process that has gone from CDI to DSF and finally to EDC/TCF.
EDC got my attention as it seems to be the first attempt to move away from dependency on GDB. The downside is that the reference TCF agent code that the target needs to host is 54,000 lines of 'C'. Also EDC seems to have been dropped from the standard CDT build which seems ominous.
I can see that developing a new debugger interface is no small task and I'd like to get off on the right foot but I'm unsure about which technology I should base my development on.
Some views and/or pointers on the following would help greatly:
1. Has ECD died on the vine, if so why?
2. Is there a preferred route for CDT debugger development?
3. Which technology base would result in the least amount of new code and heartache?
4. Is there anything round the corner I should know about.
Thanks in advance.
Cheers, Steve.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
