Bug 34745 - Implementation of python gdb helpers
Summary: Implementation of python gdb helpers
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: David Tardon
QA Contact:
URL:
Whiteboard:
Keywords:
: 38843 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-02-25 17:11 UTC by Dave Malcolm
Modified: 2011-08-25 01:49 UTC (History)
5 users (show)

See Also:


Attachments
Work in progress prettyprinting hooks for (String*) (1.20 KB, text/plain)
2011-02-25 17:13 UTC, Dave Malcolm
Details
Work in progress unit test for gdb python prettyprinting hooks for (String*) (3.08 KB, text/plain)
2011-02-25 17:17 UTC, Dave Malcolm
Details
alternative impl. of the same (and more) (9.62 KB, application/x-bzip2)
2011-03-15 00:17 UTC, David Tardon
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Malcolm 2011-02-25 17:11:43 UTC
I've had a go at implementing gdb prettyprinters for the (String*) type, as per:
http://wiki.documentfoundation.org/Development/Easy_Hacks#Implement_python_gdb_helpers

I actually developed this against Fedora 13's build of OpenOffice (specifically, using openoffice.org-impress-3.2.0-12.35.fc13.x86_64), but I'm assuming that these types haven't changed yet.

As written, this currently only works for pure-ASCII strings, but I wanted to post the code somewhere for initial review.

I also haven't yet made any attempt to autoregister the code; I've been testing this by putting the directory containing libreoffice.py in sys.path via:

$ PYTHONPATH=$(pwd) gdb /usr/lib64/openoffice.org3/program/simpress.bin

A similar hack can be seen in the automated test suite.
Comment 1 Dave Malcolm 2011-02-25 17:13:41 UTC
Created attachment 43843 [details]
Work in progress prettyprinting hooks for (String*)

I'm currently manually registering the hooks using:

  (gdb) python import libreoffice

and reloading them on edits using:

  (gdb) python reload(libreoffice)

with PYTHONPATH set up in gdb's environment to find the module.
Comment 2 Dave Malcolm 2011-02-25 17:17:48 UTC
Created attachment 43844 [details]
Work in progress unit test for gdb python prettyprinting hooks for (String*)

This is an attempt at an automated test suite for the prettyprinting hook for (String*).

It launches my machines' copy of oo-impress under gdb (with a hardcoded path...) sets up some strategically-placed breakpoints, and tried to verify how a (String*) is printed.

I'm currently invoking this using:
  PYTHONPATH=$(pwd) python selftest.py
so that the gdb subprocess it launches can find and "manually" import the libreoffice.py
Comment 3 Dave Malcolm 2011-02-25 17:30:00 UTC
Example of using this:

(gdb) p pSVData->maAppData
$38 = {mxMSF = {<com::sun::star::uno::BaseReference> = {_pInterface = 0x7f842da00058}, <No data fields>}, mpMSFTempFileName = NULL, mpSettings = 
    0x7f84338c1a88, mpEventListeners = 0x7f842941fcf0, mpKeyListeners = 0x0, mpAccelMgr = 0x0, mpAppName = String('soffice'), mpAppFileName = 
    String('/usr/lib64/openoffice.org3/program/simpress.bin'), mpDisplayName = String('OpenOffice.org 3.2 '), mpFontPath = NULL, mpHelp = 0x7f84294e2df8, 
  mpActivePopupMenu = 0x0, mpUniqueIdCont = 0x0, mpIdleMgr = 0x0, mpWheelWindow = 0x0, mpFirstHotKey = 0x0, mpFirstEventHook = 0x0, mnLastInputTime = 
    1298678455398, mnDispatchLevel = 1, mnModalMode = 0, mnModalDialog = 0, mnAccessCount = 0, mnSysWinMode = 2, mnLayout = 0, mnDialogScaleX = 10, 
  mbInAppMain = 1 '\001', mbInAppExecute = 1 '\001', mbAppQuit = 0 '\000', mbSettingsInit = 1 '\001', mbDialogCancel = 0 '\000', meShowImeStatusWindow = 
    ImplSVAppData::ImeStatusWindowMode_UNKNOWN}

Note the various "String()" values within the compound printout
Comment 4 Dave Malcolm 2011-02-25 17:33:09 UTC
(In reply to comment #2)
> Created an attachment (id=43844) [details]
> Work in progress unit test for gdb python prettyprinting hooks for (String*)
> 
> This is an attempt at an automated test suite for the prettyprinting hook for
> (String*).
> 
> It launches my machines' copy of oo-impress under gdb (with a hardcoded
> path...) sets up some strategically-placed breakpoints, and tried to verify how
> a (String*) is printed.
This particular test only works if the app is not already running; it seems to fall victim to the single-instancing code.  Ideas for a more minimal testcase welcome (perhaps a minimal app linked against the libraries, or using python's ctypes code on the dynamic lib?)
Comment 5 Dave Malcolm 2011-02-25 17:53:52 UTC
The following may or may not fix things for unicode.  Is there a convenient way to access some realworld strings that access the full range of valid values?

I tried running simpress.bin with LANG=ja_JP.utf8 in the env, but wasn't able to easily locate a (String*) that wasn't just pure ASCII.

--- a/libreoffice.py
+++ b/libreoffice.py
@@ -18,9 +18,8 @@ class StringPrinter(object):
         maStr = mpData['maStr'] # microoptimization
         # print maStr
 
-        # FIXME: this assumes ASCII
-        result = ''.join([chr(int(maStr[i]))
-                          for i in xrange(length)])
+        result = u''.join([unichr(int(maStr[i]))
+                           for i in xrange(length)])
         return "String(%r)" % result
Comment 6 Tom Tromey 2011-02-25 18:27:58 UTC
A few minor notes on the gdb side

It is maybe more gdb-ish for StringPrinter to provide
a display hint of 'string' instead of returning "String('whatever')"
But this is up to you.

If you do this then instead of the safety limit you can just
use gdb's Value.lazy_string method to specify the length (if known)
and the encoding (if known).  This lets gdb try harder to respect
various CLI settings like "set print length".

We enhanced the pretty-printer registration stuff in CVS HEAD;
if you use it then users can easily enable or disable individual printers.
It is easy to make this work in a backward-compatible way, so printers
will continue to work with gdb <= 7.2.  I can send you some code
doing this if you want.
Comment 7 Caolán McNamara 2011-03-01 09:19:48 UTC
If you looking for some CJK strings, you could e.g. add some CJK fonts and 
add a breakpoint on "preview the fontname" inside svtools/source/control/ctrlbox.cxx and scroll down the font list until you hit some fonts titled with CJK names.
Comment 8 Michael Meeks 2011-03-01 09:30:30 UTC
Wow - this is awesome :-) I guess, mailing the developer list (no subscription required) at libreoffice@lists.freedesktop.org is the best way to get this thing noticed.

It is great to dump String, dumping the (very similar but immutable) rtl::OUString would be excellent too - and (I suppose) similar things for 'ByteString' and 'rtl::OString' would be even better.

But this is fantastic as it is - I wonder, can we get it into git and install it in some libreoffice-dev package so more people can get and use it easily ?
Comment 9 David Tardon 2011-03-15 00:17:15 UTC
Created attachment 44461 [details]
alternative impl. of the same (and more)

FWIW, I have been using (and extending) these pretty printers for nearly 2 years now, but never actually got around to publish them :( The 'development' of them has always been a bit messy, trying new ideas and discarding them again, so some parts are more complicated than they need to be, others does not work as well as they should, yet others are mostly useless...

Usage: unpack somewhere and then export PYTHONPATH=somewhere/openoffice.org-gdb
Comment 10 Caolán McNamara 2011-03-15 02:44:36 UTC
dtardon: well in that case I feel you've selected yourself for integration of these things.

How about we stick them into the libreoffice tree somewhere, package them into a e.g. libreoffice-gdb (or into the sdk or something) and update http://wiki.documentfoundation.org/Development/How_to_debug on how to use them
Comment 11 Tom Tromey 2011-03-15 09:19:14 UTC
(In reply to comment #9)
> Created an attachment (id=44461) [details]
> alternative impl. of the same (and more)

I looked through these a little.

I think they should use gdb.Value.lazy_string when available, and
gdb.Value.string when not.  Right now they seem to create the strings
explicitly, but this is less friendly in some ways.

Also I think they could use an upgrade to the new (currently only in CVS)
printer protocol, which lets users enable or disable specific printers.
This is very easy to do in a backwards-compatible way; see (current SVN)
libstdc++ for an example.
Comment 12 David Tardon 2011-03-15 10:06:45 UTC
(In reply to comment #11)
> (In reply to comment #9)
> I think they should use gdb.Value.lazy_string when available, and
> gdb.Value.string when not.  Right now they seem to create the strings
> explicitly, but this is less friendly in some ways.

Yup, this is on my TODO list.

> Also I think they could use an upgrade to the new (currently only in CVS)
> printer protocol, which lets users enable or disable specific printers.
> This is very easy to do in a backwards-compatible way; see (current SVN)
> libstdc++ for an example.

Is it available in Fedora Rawhide? And if it is not, could it be? :)
Comment 13 Tom Tromey 2011-03-16 08:29:32 UTC
(In reply to comment #12)

> Is it available in Fedora Rawhide? And if it is not, could it be? :)

It isn't yet, but it will show up there and in F15 sometime soon.

Meanwhile you can see the latest here:

http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/python/libstdcxx/v6/

The important bits are the (conditional) use of the new gdb.printing module,
and the new Printer class that supports enablement.
Comment 14 David Tardon 2011-08-25 01:43:22 UTC
This is in master now. Sorry it took so long.
Comment 15 David Tardon 2011-08-25 01:43:44 UTC
closing
Comment 16 David Tardon 2011-08-25 01:49:39 UTC
*** Bug 38843 has been marked as a duplicate of this bug. ***