[
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.
|
I would like to correct one minor point in reference to the licensing, specifically : "...- EDL license (BSD-like)...".
The EDL *is* BSD, not "like" BSD. The New BSD is a template. All we did is fill out the template.
A nit, I know. But an important nit to some.
Mike Milinkovich
mike.milinkovich@xxxxxxxxxxx
+1.613.220.3223
-----Original Message-----
From: "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
Sender: cdt-dev-bounces@xxxxxxxxxxx
Date: Tue, 13 Nov 2012 15:52:54
To: CDT General developers list.<cdt-dev@xxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Cc: TCF Development \(tcf-dev@xxxxxxxxxxx\)<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
