Re: [cdt-dev] Customizing debug hierarchy and LaunchVMAdapter

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Vladimir Prus
> Sent: Saturday, September 13, 2014 4:01 AM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Customizing debug hierarchy and LaunchVMAdapter
> 
> On 09/11/2014 10:25 PM, Vladimir Prus wrote:
> 
> > And then, LaunchVMProvider does not make it easy to change the type of
> > a particular node, and ContainerVMNode or ThreadVMNode have fairly
> monolithic createLabelProvider.
> >
> > Am I missing something, or the overall design is presently not very
> > suited for custom debug hierarchy? Is there any work to improve that, or
> thoughts how it's best done?
> 
> I've looked more into this. The specific task at hand is that:
> 
> - DSF uses output of -thread-info command to render thread label in debug
> view
> - The typical output is as follows, wrapped for convenience:
> 
>    33^done,threads=[{id="1",target-id="hello",
>        frame={level="0",addr="0x00400535",func="main",args=[],
>               file="hello.c",
>               fullname=".../testing-upstream/hello/Debug/../src/hello.c",
>               line="24"
>               },....
> - In my case, the frame element has an extra field that I want to use in thread
> label
> 
> I had to customize these:
> 
> - MIFrame (to parse the new field)
> - MIThread (basically to copy-paste the parse method to create my new
> MIFrame subclass). I could have not
>    create a new class, but copy-paste the method into some other class - even
> worse.
> - MIThreadInfoInfo (to create my custom thread/frame classes)
> - CommandFactory_6_8 (to create my MIThreadInfoInfo)
> - GDBProcesses_7_4 (to create MIThreadDMData with a different name -
> otherwise I'd have to
>    subclass MIThreadDMData as well)
> - GdbDebugServicesFactory, to create new command factory and process
> service classes
> - ThreadVMNode, to remove label elements that are no longer relevant
> - LaunchVMProvider, to create my subclass of ThreadVMNode
> - GdbAdapterFactory, to create my subclass of LaunchVMProvider
> - Register my new adapter factory in plugin.xml
> - Create new launch delegate to create new services factory
> 
> Along the way, I had to liberally invoke "extract method" refactoring on
> existing classes.
> 
> Certainly, I would have to customize some of the above classes anyway - like
> launch delegate and ThreadVMNode. But overall, it seems to be going
> through the roof. Is it me, or others agree that this is not an extensible
> architecture at all?

You have to remember that you are extending DSF-GDB which was not originally
aimed at being extended.  Originally it was just an example.  We've come a long way :)
But I agree that if you had do to all the above changes, we should find a way to make
it easier.  I'll look at the changes in more detail to better understand your situation.

> What is particularly upsetting is that MI is naturally extensible (being basically
> a bunch of JSON-like objects), so in the ideal world, DSF-GDB would have a
> ThreadVMNode specific to MI, which would have access to the raw object
> from GDB, thereby removing the need to customize half of the classes
> above.
> Any comments on that approach?

I think MI specifics belong in the data model side of things (services and such) and should
remain out of the view model.  The raw data from GDB sometimes changes and we should
not pollute classes like ThreadVMNode with those details; the versioning of the services
allow to handle MI differences and keep it nicely(?) contained.