Re: [cdt-dev] questions about org.eclipse.cdt.dsf.gdb

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

Hi Justin,

> From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Justin You [justin.you@xxxxxxxxxxxx]
> Sent: January 14, 2016 4:48 AM
> To: cdt-dev@xxxxxxxxxxx
> Subject: [cdt-dev] questions about org.eclipse.cdt.dsf.gdb
> 
> Hi CDT:
>  
> I am working for integrating our internal debugger into CDT by DSF. I am asking some help here. Thanks in advance.
>  
> 1.      
> I have learned the example project org.eclipse.cdt.examples.dsf.gdb and org.eclipse.cdt.examples.dsf.pda. I understood them well. I am studying the project org.eclipse.cdt.dsf.gdb.
>  it’s a little of complexity gap between this project and DSF-PDA example. Are there any overview design doc for project org.eclipse.cdt.dsf.gdb?

Yes, the dsf.gdb project has grown much beyond being an example of DSF, so the complexity has increased a lot.  Sadly, we don't have any written documentation for DSF-GDB specifically.  There is a nice tutorial on DSF though: 
http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.cdt.doc.isv%2Fguide%2Fdsf%2Fintro%2Fdsf_programming_intro.html&cp=14_0_5

The reality is that DSF-GDB is pretty active and the code keeps evolving to bring in new features and stay in sync with new GDB releases, so part of any documentation would quickly become obsolete.

> 2.      
> Why do separate GDB-MI into two groups? There are org.eclipse.cdt.dsf.mi.service VS org.eclipse.cdt.dsf.gdb.service? org.eclipse.cdt.dsf.mi.service.commnad VS org.eclipse.cdt.dsf.gdb.service
>  command? Etc.

This is historical (and not useful anymore).  WindRiver, who contributed DSF, had their own MI debugger so they had the dsf.mi.service set of classes support generic MI (their debugger and GDB) while the dsf.gdb.service was meant to support any behaviour that was specific to GDB.  Today, we are fully focused on GDB and we no longer make that difference, but the old code remains.

> 3.     
> Our debugger is not a GDB dialect and doesn’t support MI protocol or similar machine protocol yet. There are several choices now.
> a.     
> The first is to implement it from scratch and don’t reuse DSF-GDB anyway.

This has been done by others in the community and really is what DSF is meant to be used as.  DSF-GDB was meant to be an example on how to do this.  There is another open-source example (that is not active anymore) called EDC.  You can find the code here: http://git.eclipse.org/c/cdt/org.eclipse.cdt.edc.git and a description here: https://wiki.eclipse.org/CDT/cdt-debug-edc.  You will be able to get more help on DSF-GDB though

> b.     
> The second is to implement a debugger-MI driver for our debugger to reuse DSF-GDB.

That is another good approach.  You would then get most of the DSF-GDB features automatically, and keep getting any new ones, as long as your backend supports them.  This is the approach that is currently the plan to integrate LLDB with DSF.

> c.      
> What’s the pros/cons for these two paths? Are there any third path? Thanks.

Those are the two main paths to integrate with DSF.
A third approach would be not to use DSF at all and integrate directly on top of platform's flexible hierarchy.  This is what the TCF debugger does.

I don't have experience with all three approaches so my view of things is a little biased and may be simplistic.  I think it comes down to flexibility vs re-use.  The lower you go (platform being the lowest and DSF-GDB the highest), the most flexibility you'll have to do exactly what you want, but you'll also have to do more work yourself.  The higher you go, the most existing support you will be able to re-use and the most support you'll get from the community.  With the trend everywhere being in re-using more than writing from scratch, I'm leaning towards re-using existing integrations.

If you consider taking the DSF-GDB road, you may want to investigate how hard it would be to provide an MI layer on top of your debugger.

I hope this helps.

Marc