Extending a debugger for data inspection and visualization

[Niko Sams]

Sorry for the late reply.

>  I looked up kdevplatform/debugger/variable/variablecollection.{h,cpp}.
> Please confirm if I understand the following points. Then please help me with
> my questions that follow.
>
> * the classes there are treeitems that will appear in the variable-widget's
> variable tree.
>
> * There seem to be two principal categories right now : locals and watches.
confirmed.

> * There used to be a third category of evaluated expressions under
> the "Recent" tree header item in KDev3 but it has probably been absorbed into
> one of the above or will be generated when the user requests one for the
> first time.
I know nothing about kdev3 :D

> QUESTIONS:
>
> * Data inspection nodes like visualization and memory tables will be special
> kinds of expressions which require reading arrays of data from memory. Will
> we need a new subclass of Variable or TreeItem to handle these?
I don't think you should read memory directly. Except for simple things like a
plain int[] array you  can't find out anything by reading just the memory.
Think of QList with it's implicit sharing.

> * Can these nodes be given a separate heading like "Data Inspection" which
> appears as a sibling to Locals and Watches? While these behave as
> expressions, they won't exactly be expressions because they may require
> auxiliary user-data to function. For example, a "complex<double> matrix" view
> of memory will require additional information like whether the data is laid
> out in row-major or column-major formats and the stride between rows or
> columns in either case.
Could you create a mockup or something how you plan this? I don't know how
this should be integrated in the variable view...

> * In KDev3 there was a memory-viewer widget which allowed examination of a hex
> dump of memory. A data-inspection widget is the generalization where we can
> view memory according to some schema (like a structure) given the starting
> address, schema and layout information. At the outset this is easy to achieve
> with simple types like int, float, double etc. that extend the basic view of
> memory as bytes. Does this seem like a useful feature?
again - please create a mockup. And as I said above - not everything
is a struct with
simple types.

> * Tabulation or graphing of data is a matter of representation and therefore
> we have a MVC paradigm here. Because of the debugger abstraction, can all
> this be folded into a debugger-independent plugin? If so what classes and
> methods should I begin looking at to extract the relevant information from
> the debugger? I have noticed that IDebugController returns a
> VariableCollection*. Once I setup a slot to receive its
> sessionAdded(KDevelop::IDebugSession*) signal, I should be able to get all
> this information from VariableCollection, correct? From this I can list
> various variable objects but how do I go about evaluating them and extracting
> array data? In the case of strided-data I will need multiple calls to the
> debugger to retrieve data-set pieces which I will then need to assemble
> together form a coherent data-model.
Using VariableCollection is not so easy i think, because it's
optimized for displaying
in a TreeView.
What data do you need? We could find a way to get that efficient by
adding methods
to IVariableController.
Alternatively you could fetch the data yourself - but then it can't be debugger
independent and you have to link to the gdb plugin in some way.
(But this might be easier to implement)


Niko