[
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.
|
Hi Doug,
Thanks for the comments.
I've built and run the PDA debug example and was impressed by what you
can get from such a minimalistic example.
I'm really trying to keep away from GDB/GDB server. Portability and
version compatibility are real problems. Once you get it working it's
great but it has never "just worked" for me. I'm also looking at hooking
into a Java based emulator so having GDB in the middle here would look
eccentric to say the least.
I'm thinking an external "TCF agent" that wraps JTAG would make most
sense. With this hanging off a socket am I right in thinking CDT debug
would not need any new plug-ins?
I can see from yours and Marc's comments that DSF is the preferred
route. Do you think TCF a based debug solution has a future or is there
a good chance TCF will go the same way as EDC?
Cheers, Steve
On 13/11/2012 14:35, Doug Schaefer wrote:
Yeah, EDC is dead in the water. We don't even build it any more. If TCF
interests you, it's still running and has debug capability which is
different than what EDC provided (which was also part of the problem). But
DSF is generally what CDT adopters are using these days.
While I agree with Marc that implementing the gdb serial protocol is a
good way to go, if your processor is so different gdb can't support it at
all then it'll have trouble walking stacks and interpreting symbols and
stuff.
There's a PDA example project in the CDT source that shows how to use raw
DSF if you need to build a new debugger from scratch. Pawel could comment
more on that.
Doug.
On 12-11-13 9:27 AM, "Marc Khouzam"<marc.khouzam@xxxxxxxxxxxx> wrote:
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Steve Jones
Sent: Tuesday, November 13, 2012 4:19 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Writing a CDT debugger for a none GDB target.
Hi,
Hi Steve,
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.
That is not quite right. It has gone from CDI to DSF with the
parallel track of EDC (which is no longer actively worked
on, see below).
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.
You are right that it is not a small task. I find the fastest
solution is code re-use (see below).
Some views and/or pointers on the following would help greatly:
1. Has EDC died on the vine, if so why?
EDC was an effort supported by Nokia. They have since
stopped working on it and there are no active committers focusing
in EDC. I don't believe the effort has been picked up by others.
2. Is there a preferred route for CDT debugger development?
CDI or EDC are not actively being worked on.
DSF-GDB is the default debugger for CDT and is constantly being
improved (both in CDT but also in GDB itself).
3. Which technology base would result in the least amount of new code
and heartache?
What my company does is focus on DSF and GDB, and write a small
gdbstub (a la gdbserver) for our different targets.
That allows each target to re-use the existing CDT DSF-GDB
solution directly.
In your case, you says that your processor is not supported by
the GDB debugger. However, getting a gdbstub working for your
processor may be the simplest thing to do. It is kind of porting
gdbserver to your processor. gdbserver is much simpler than GDB,
and porting it seems to be something that can be relatively easy.
Then you get all of the features of GDB, and all the debug features
of CDT automatically.
4. Is there anything round the corner I should know about.
More features being added to GDB and DSF-GDB :)
I hope this helps.
Marc
_______________________________________________
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
