[python] Pretty-printers and addressprint

[python] Pretty-printers and addressprint

[Paul Pluzhnikov]

Greetings,

Consider the gdb.python/py-prettyprint.exp test case.
It has:

typedef struct string_repr
{
  struct whybother
  {
    const char *contents;
  } whybother;
} string;

and a prettyprinter for it:

# Test returning a Value from a printer.
class string_print:
    def __init__(self, val):
        self.val = val

    def to_string(self):
        return self.val['whybother']['contents']


Which currently produces:

$4 = 0x4007e0 "this is x"^M


The issue I am having is there is no apparent way to get rid of the
address from python side (address is not printed when the printer
returns a python string instead of a value), whereas if the
printer really wants to print the address, it can trivally add
it back by returning appropriate python string.

Printing addresses inside of a container seems to be especially
"not wanted".

Should the decision to print addresses be deferred to the
pretty-printer? Is the patch below reasonable?

Thanks,
--
Paul Pluzhnikov

2009-11-09  Paul Pluzhnikov  <ppluzhnikov@google.com>

	* gdb/python/py-prettyprint.c (print_string_repr): Don't
	print value address.



--- gdb/python/py-prettyprint.c#1    2009-11-09 17:58:39.000000000 -0800
+++ gdb/python/py-prettyprint.c     2009-11-09 16:51:16.862840000 -0800
@@ -209,7 +209,12 @@ print_string_repr (PyObject *printer, co
       Py_DECREF (py_str);
     }
   else if (replacement)
-    common_val_print (replacement, stream, recurse, options, language);
+    {
+      struct value_print_options opts = *options;
+
+      opts.addressprint = 0;
+      common_val_print (replacement, stream, recurse, &opts, language);
+    }
   else
     gdbpy_print_stack ();
 }

RE: [python] Pretty-printers and addressprint

[Elmenthaler, Jens]

Hi Paul,

The gdb.Value class has a string() method, you could try this in your to_string method:
	return self.val['whybother']['contents'].string()

Greetings, Jens.

-----Original Message-----
From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf Of Paul Pluzhnikov
Sent: Dienstag, 10. November 2009 03:12
To: gdb@sourceware.org; archer@sourceware.org
Cc: dje@google.com; ppluzhnikov@google.com
Subject: [python] Pretty-printers and addressprint

Greetings,

Consider the gdb.python/py-prettyprint.exp test case.
It has:

typedef struct string_repr
{
  struct whybother
  {
    const char *contents;
  } whybother;
} string;

and a prettyprinter for it:

# Test returning a Value from a printer.
class string_print:
    def __init__(self, val):
        self.val = val

    def to_string(self):
        return self.val['whybother']['contents']


Which currently produces:

$4 = 0x4007e0 "this is x"^M


The issue I am having is there is no apparent way to get rid of the
address from python side (address is not printed when the printer
returns a python string instead of a value), whereas if the
printer really wants to print the address, it can trivally add
it back by returning appropriate python string.

Printing addresses inside of a container seems to be especially
"not wanted".

Should the decision to print addresses be deferred to the
pretty-printer? Is the patch below reasonable?

Thanks,
--
Paul Pluzhnikov

2009-11-09  Paul Pluzhnikov  <ppluzhnikov@google.com>

	* gdb/python/py-prettyprint.c (print_string_repr): Don't
	print value address.



--- gdb/python/py-prettyprint.c#1    2009-11-09 17:58:39.000000000 -0800
+++ gdb/python/py-prettyprint.c     2009-11-09 16:51:16.862840000 -0800
@@ -209,7 +209,12 @@ print_string_repr (PyObject *printer, co
       Py_DECREF (py_str);
     }
   else if (replacement)
-    common_val_print (replacement, stream, recurse, options, language);
+    {
+      struct value_print_options opts = *options;
+
+      opts.addressprint = 0;
+      common_val_print (replacement, stream, recurse, &opts, language);
+    }
   else
     gdbpy_print_stack ();
 }

Re: [python] Pretty-printers and addressprint

[Paul Pluzhnikov]

On Mon, Nov 9, 2009 at 11:25 PM, Elmenthaler, Jens
<jens.elmenthaler@verigy.com> wrote:

> The gdb.Value class has a string() method, you could try this in your to_string method:
>        return self.val['whybother']['contents'].string()

That doesn't quite do what I want, but this almost does:

        return '"' + self.val['whybother']['contents'].string() + '"'

However, consider a modification of the original test:

-  string x = make_string ("this is x");
+  string x = make_string ("this is x\201\202\203\204");


With the original pretty-printer, this produces:

  $4 = 0x4007e0 "this is x\201\202\203\204"

which is exactly what I want, if only it didn't have the address. With
proposed patch, it produces exactly what I want:

  $4 = "this is x\201\202\203\204"

But this value can't be converted to a python string in ASCII charset:
the modified printer produces this:

  $4 = Traceback (most recent call last):
    File "../../../src/gdb/testsuite/gdb.python/py-prettyprint.py",
line 27, in to_string
      return self.val['whybother']['contents'].string()
  UnicodeDecodeError: 'ascii' codec can't decode byte 0x81 in position
9: ordinal not in range(128)

Unfortunately I frequently deal with non-ascii strings, and the
problem just wouldn't go away :-(

Previous threads on this subject, e.g.
http://sourceware.org/ml/archer/2008-q4/msg00180.html didn't appear to
have reached a satisfactory conclusion.


Thanks,
-- 
Paul Pluzhnikov

Re: [python] Pretty-printers and addressprint

[Phil Muldoon]

On 11/10/2009 08:06 AM, Paul Pluzhnikov wrote:
>
> Unfortunately I frequently deal with non-ascii strings, and the
> problem just wouldn't go away :-(
>
> Previous threads on this subject, e.g.
> http://sourceware.org/ml/archer/2008-q4/msg00180.html didn't appear to
> have reached a satisfactory conclusion.
>
>    

There is a bug that tracks this now:

http://sourceware.org/bugzilla/show_bug.cgi?id=10705

But I think (also) what you are asking for is a way to get at the 
underlying data without passing it through an encoding?

Cheers,

Phil

Re: [python] Pretty-printers and addressprint

[André Pönitz]

On Tuesday 10 November 2009 09:36:49 Phil Muldoon wrote:
> On 11/10/2009 08:06 AM, Paul Pluzhnikov wrote:
> >
> > Unfortunately I frequently deal with non-ascii strings, and the
> > problem just wouldn't go away :-(
> >
> > Previous threads on this subject, e.g.
> > http://sourceware.org/ml/archer/2008-q4/msg00180.html didn't appear to
> > have reached a satisfactory conclusion.
> >
> >    
> 
> There is a bug that tracks this now:
> 
> http://sourceware.org/bugzilla/show_bug.cgi?id=10705
> 
> But I think (also) what you are asking for is a way to get at the 
> underlying data without passing it through an encoding?

That would be useful in my opinion. Even if the proper encoding were 
known, data could still be corrupted. Getting direct access to the
real data would be nice, even though it is already possible right 
now using 'manual' iteration the data using a "char *" value.

Andre'

Re: [python] Pretty-printers and addressprint

[Tom Tromey]

>>>>> "André" == André Pönitz <andre.poenitz@nokia.com> writes:

André> That would be useful in my opinion. Even if the proper encoding were 
André> known, data could still be corrupted. Getting direct access to the
André> real data would be nice, even though it is already possible right 
André> now using 'manual' iteration the data using a "char *" value.

The branch in the archer repository has some memory-reading functions in
the Python API that should be useful for accessing the raw bits.
Those are probably reasonably ready for pushing into CVS -- Thiago is
the real expert here, maybe he could say.

Tom

RE: [python] Pretty-printers and addressprint

[Paul Koning]

> On Mon, Nov 9, 2009 at 11:25 PM, Elmenthaler, Jens
> <jens.elmenthaler@verigy.com> wrote:
> 
> > The gdb.Value class has a string() method, you could try this in your
> to_string method:
> >        return self.val['whybother']['contents'].string()
> 
> That doesn't quite do what I want, but this almost does:
> 
>         return '"' + self.val['whybother']['contents'].string() + '"'

Try instead 
    return repr (self.val...)

rather than manually supplying the quotes.  That will do the right thing even if the contents has things like quotes in it.
 
> However, consider a modification of the original test:
> 
> -  string x = make_string ("this is x");
> +  string x = make_string ("this is x\201\202\203\204");
> ... 
> But this value can't be converted to a python string in ASCII charset:
> the modified printer produces this:
> 
>   $4 = Traceback (most recent call last):
>     File "../../../src/gdb/testsuite/gdb.python/py-prettyprint.py",
> line 27, in to_string
>       return self.val['whybother']['contents'].string()
>   UnicodeDecodeError: 'ascii' codec can't decode byte 0x81 in position
> 9: ordinal not in range(128)
> 
> Unfortunately I frequently deal with non-ascii strings, and the
> problem just wouldn't go away :-(

My test (without gdb, I don't have that installed yet) is inconclusive but I think using repr() will cure that too.

	paul

Re: [python] Pretty-printers and addressprint

[Paul Pluzhnikov]

On Tue, Nov 10, 2009 at 3:53 AM, Paul Koning <Paul_Koning@dell.com> wrote:

>> Unfortunately I frequently deal with non-ascii strings, and the
>> problem just wouldn't go away :-(
>
> My test (without gdb, I don't have that installed yet) is inconclusive
> but I think using repr() will cure that too.

AFAICT, in GDB repr(value) is a no-op, and the end result of returning
repr(value) from the pretty-printer is exactly the same as that of
returning the value itself:

  $4 = 0x4007e0 "this is x\201\202\203\204"

Should repr(value) do something different?

Thanks,
-- 
Paul Pluzhnikov

RE: [python] Pretty-printers and addressprint

[Paul Koning]

repr() is a Python builtin function that returns the "representation" of
an object -- a string that matches the representation of that object in
Python.  Contrast that with str() which prints it the user-friendly way
which may be less complete.

For example:

python
Python 2.5.1 (r251:54863, Feb  6 2009, 19:02:12) 
>>> foo="abc\1"
>>> print foo
abc
>>> print repr(foo)
'abc\x01'
>>> print str(foo)
abc
>>>  

Note that "repr" puts quotes around the string, and escapes the
non-printable characters.  It also escapes quotes, which simply wrapping
a quote around the raw string won't cover.

If in gdb repr() doesn't work as in standard Python that would be a
problem...

	paul

> -----Original Message-----
> From: Paul Pluzhnikov [mailto:ppluzhnikov@google.com]
> Sent: Tuesday, November 10, 2009 10:45 AM
> To: Paul Koning
> Cc: Elmenthaler, Jens; gdb@sourceware.org; archer@sourceware.org;
> dje@google.com
> Subject: Re: [python] Pretty-printers and addressprint
> 
> On Tue, Nov 10, 2009 at 3:53 AM, Paul Koning <Paul_Koning@dell.com>
> wrote:
> 
> >> Unfortunately I frequently deal with non-ascii strings, and the
> >> problem just wouldn't go away :-(
> >
> > My test (without gdb, I don't have that installed yet) is
> inconclusive
> > but I think using repr() will cure that too.
> 
> AFAICT, in GDB repr(value) is a no-op, and the end result of returning
> repr(value) from the pretty-printer is exactly the same as that of
> returning the value itself:
> 
>   $4 = 0x4007e0 "this is x\201\202\203\204"
> 
> Should repr(value) do something different?
> 
> Thanks,
> --
> Paul Pluzhnikov

Re: [python] Pretty-printers and addressprint

[Tom Tromey]

>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:

Paul> AFAICT, in GDB repr(value) is a no-op, and the end result of returning
Paul> repr(value) from the pretty-printer is exactly the same as that of
Paul> returning the value itself:

That is because repr(value) ends up in valpy_str, which calls
common_val_print.

What you want instead is repr(value.string()), at least if you want to
try this route.

Tom

Re: [python] Pretty-printers and addressprint

[Paul Pluzhnikov]

On Tue, Nov 10, 2009 at 8:53 AM, Tom Tromey <tromey@redhat.com> wrote:

> What you want instead is repr(value.string()), at least if you want to
> try this route.

That of course can't work, since it's the value.string() which
raises exception. Here is the output:

$4 = Traceback (most recent call last):
  File "../../../src/gdb/testsuite/gdb.python/py-prettyprint.py", line
27, in to_string
    return repr(self.val['whybother']['contents'].string())
UnicodeDecodeError: 'ascii' codec can't decode byte 0x81 in position
9: ordinal not in range(128)


It also changes other output in the way I didn't expect:

print cstring
$5 = u'const string'

print c
$6 = container u'container' with 2 elements = {
  [0] = 23,
  [1] = 72
}

Thanks,
-- 
Paul Pluzhnikov

Re: [python] Pretty-printers and addressprint

[Tom Tromey]

>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:

>> What you want instead is repr(value.string()), at least if you want to
>> try this route.

Paul> That of course can't work, since it's the value.string() which
Paul> raises exception.

Yeah, oops on me.

I think your patch was fine.  Or, if people don't like that, we can
always have an "addressprint for pretty-printing" option.

Tom

Re: [python] Pretty-printers and addressprint

[Tom Tromey]

>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:

Paul> The issue I am having is there is no apparent way to get rid of the
Paul> address from python side (address is not printed when the printer
Paul> returns a python string instead of a value), whereas if the
Paul> printer really wants to print the address, it can trivally add
Paul> it back by returning appropriate python string.

Adding it manually like that will also affect MI output, which may not
be what you really want.

Paul> Should the decision to print addresses be deferred to the
Paul> pretty-printer? Is the patch below reasonable?

I'm ok with it.  If nobody complains this week, check it in.

Tom