Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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?

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?

--
Vladimir Prus
CodeSourcery / Mentor Graphics
http://www.mentor.com/embedded-software/

Back to the top