Re: [Swig-devel] Graphical Debugging / GDB Pretty Printer

[William S F. <ws...@fu...>]

On 21 July 2012 01:32, Oliver Buchtala <oli...@go...> wrote:
> On 20.07.2012 08:02, William S Fulton wrote:
>>
>> On 14/07/12 00:51, Oliver Buchtala wrote:
>>>
>>> Hi Swiggers,
>>>
>>> I created a document that describes how to install a gdb pretty-printer
>>> (ehm - mine :) ) for SWIG types and shows some example graphical
>>> debuggers:
>>> http://substance.io/oliver/swig-graphical-debugger
>>>
>>> The pretty-printer is a python class using the GDB python API which is
>>> part of GDB since version 7.
>>> It is the initial version so bugs are expectable. Also GDB has still
>>> bugs itself in that API (e.g., cyclic references).
>>> Though, I think it is already very useful and maybe open the world of
>>> debugging to SWIG developing beginners.
>>>
>>> I would be glad, if someone tried and report issues on
>>> https://github.com/oliver----/gsoc2012-javascript/issues
>>> or give me feedback per mail.
>>
>>
>> This looks rather good, but my gdb is too old to try it out. I'll install
>> a new one in the near future and try it out and send some feedback.
>>
>> Does it work with gdbtui when using gdb's print? The current
>> Tools/swig.gdb isn't very compatible because it outputs to stdout which
>> messes up the whole display. Also related, I presume gdb's 'print' work?
>> Screenshots of both plain gdb and gdb with tui would be good to see in the
>> docs.
>>
>> William
>>
>
> Actually I am not familiar with gdbtui.
This is easy to try out, at the gdb prompt:

(gdb) win

then a window will appear and you can use gdb commands as normal but
you get to see the source file and highlighted lines. The ctrl-x a key
is meant to get out of this mode (it doesn't always work for me.) Your
swigprinters do work when the tui windows is showing and I just
thought of a fix for the swig.gdb problems where using 'swigprint' and
'locswigprint' was corrupting the display. I've just committed a fix
and now they also display in the gdb window in Eclipse.

> But in general on gdb CLI it does
> work...
> There is only a small clitch I am discussing with the gdb crew.
> For using those pretty printers in the gdb CLI one has to set a flag to
> circumvent that problem (as a workaround for the meantime).
>
> The output looks like this:
> $3 = Node * = {
>   [name] = "area",
>   [ismember] = "1",
>   [sym:symtab] = 0x7ffff7f78cb0,
>   [nodeType] = "cdecl",
>   [nextSibling] = 0x7ffff7f79530,
>   [kind] = "function",
>   [memberfunctionHandler:sym:name] = "area",
>   [sym:name] = "Circle_area",
>   [view] = "memberfunctionHandler",
>   [memberfunctionHandler:type] = "double",
>   [memberfunctionHandler:parms] = 0x7ffff7f56010,
>   [parentNode] = 0x7ffff7f78af0,
>   [decl] = "f().",
>   [access] = "public",
>   [parms] = 0x7ffff7f81c50,
>   [wrap:action] = "result = (double)(arg1)->area();",
>   [type] = "double",
>   [wrap:name] = "Circle_area",
>   [sym:overname] = "__SWIG_0",
>   [memberfunctionHandler:value] = 0x7ffff7f56010,
>   [memberfunctionHandler:name] = "area"
> }
>
> Here also due to an existing bug in the gdb python API, only one level is
> possible (~cyclic references in Hashes).
> This hopefully improves soon ... I filed that bug.

To make this a no-brainer 'install' for users, I was hoping to put
swigprinters.gdb and swigprinters.py in the same directory (Tools) and
have a single line in my ~/.gdbinit file, such as:

source ~/swig/trunk/Tools/swigprinters.gdb

with generic contents to set the sys path to wherever the
swigprinters.gdb file is:

python
import sys
import os

sys.path.insert(0, os.path.realpath(__file__))
from swigprinters import register_swig_printers
register_swig_printers (None)

end

but gdb must be running python as embedded interpreter and __file__
does not exist so this approach is not going to work. I had a quick
look at the gdb package to see if it gave the current .gdb filename,
but couldn't see anything. Have you got any other ideas to achieve
this easy to install goal?

The swig.gdb functionality works alongside your swigprinters which is
cool. I'd like to see both approaches to gdb debugging shipped with
SWIG. Could you  them to the Tools directory in trunk when you are
ready and update the Doc/Devel/internals.html with your documentation.

Not sure it is fully working atm though, compare with swigprint:

(gdb) p n
$2 = Node * = {["destructorDeclaration"] = "~Shape", ["1"] =
0x7ffff7fbd430, ["destructor"] = 0x7ffff7fbda70, ["delete_Shape"] =
"~Shape", ["destructorHandler"] = "Shape", [
    0x7ffff7f59010] = 0x7ffff7f59010, [0x7ffff7fbd270] = "~Shape",
["f()."] = "typesafe", ["public"] = 0x7ffff7eb2370, ["delete arg1;"] =
"void", ["{\n    nshapes--;\n  }"] =
    "__SWIG_0", ["virtual"] = "~Shape"}
(gdb) swigprint n
Hash(0xf7fbd7b0) {
  'destructorHandler:view' : destructorDeclaration,
  'name' : ~Shape,
  'ismember' : 1,
  'sym:symtab' : Hash(0xf7fbd430) {......},
  'nodeType' : destructor,
  'nextSibling' : Hash(0xf7fbda70) {.............},
  'sym:name' : delete_Shape,
  'destructorDeclaration:sym:name' : ~Shape,
  'view' : destructorHandler,
  'destructorHandler:sym:name' : Shape,
  'destructorHandler:type' : <Object 'VoidObj' at 0x7ffff7f59010>,
  'destructorHandler:parms' : <Object 'VoidObj' at 0x7ffff7f59010>,
  'parentNode' : Hash(0xf7fbd270) {...........................},
  'destructorDeclaration:name' : ~Shape,
  'decl' : f().,
  'feature:java:enum' : typesafe,
  'access' : public,
  'parms' : Hash(0xf7eb2370) {......},
  'wrap:action' : delete arg1;,
  'type' : void,
  'code' : {
    nshapes--;
  },
  'sym:overname' : __SWIG_0,
  'storage' : virtual,
  'destructorHandler:name' : ~Shape,
}
(gdb)

Do you not get this?

William