Re: [cdt-dev] Writing a CDT debugger for a none GDB target.

[Doug Schaefer <dschaefer@xxxxxxx>]

There are some big names behind TCF so I have a feeling it'll stick
around. Certainly worth looking at.

Doug.

On 12-11-13 11:17 AM, "Steve Jones" <steve@xxxxxxxxxxxxxxxxxx> wrote:

>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
>>
>
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/cdt-dev