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/16/2014 08:55 PM, Marc Khouzam wrote:

-----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 :)


For avoidance of doubt, I hope we no longer consider DSF-GDB as 'just an example'? ;-)


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.


I do not propose that ThreadVMNode know anything about MI per se. What I do propose is that
MIThreadData keeps a copy of MITuple that was returned by GDB. In fact, better not even MI
tuple, but some generic JSON property tree class. This way, if my custom GDB adds a field,
then my custom ThreadVMNode subclass can access it - without even being tied to MI, all
I need to know is that thread has frame property which has an extra property I need to access.

What I propose is probably in line with what is already done, where
ThreadVMNode.updatePropertiesInSessionThread and fillThreadDataProperties create 'generic' properties,
but they are really very much dependent on both what GDB implementation, and specific IGdbThreadDMData
interface. All that I propose is that new fields of threads and frames can be propagated via
IGdbThreadDMData without creating new classes or new methods.

- Volodya

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

Back to the top