headers
Tom Tromey | 1 Oct 2008 02:34
Picon
Favicon

Meeting Agenda 2008-10-01

Tomorrow we're having a meeting.  The time and dial-in info is as
usual; I've appended it for reference.

My agenda tomorrow:

1. Individual status on estimates.
2. Discussion of expression estimates (basically I am curious about
   the 'new' thing)
3. Discussion of "catch syscall"

Nobody sent extra agenda items, but we can always add more if needed.

Tom

Dial-in info:

 8:30 am Pacific
 9:30 am Mountain
11:30 am Eastern
 4:30 pm Wales
 5:30 pm Czech Republic (I think)

The phone # is:

+1 919-334-5215 or 888-HELLO-RH (888-435-5674 NAmericaOnly)

The participant code is "379752", aka "frysk2".
Permalink | Reply | 0 comments |
headers
André Pönitz | 1 Oct 2008 10:47

Re: pretty-printing update

On Tuesday 30 September 2008 21:57:08 Tom Tromey wrote:
> I've been working on pretty printing for the past week; I thought I'd
> send a note about the current status.
>  [...]
> There are a couple problems right now.
> 
> The biggest one is that the output is not always actually pretty.  It
> is an improvement, in that you can easily see the contents of
> containers and whatnot, but the formatting is odd.  Consider this
> example, where 'intmap' is a std::map<int, char*>:
> 
> (gdb) p intmap
> $2 = number of elements = 2
> [5] = 0x804c057 "liver"
> [23] = 0x804c046 "maude"
> [...]
> If you've got any input on these, I'm all ears.

It depends a bit on who is going to read this output. The output
above is surely good enough for an interactive session, and in
that case the "$2" does not really hurt. 

For  a "machine" interface, something more structured (and more
robust to parse) would be needed anyway.

Solutions for that are not hard. As an example, a  std::list<std::string> 
with three elements "aaa", "b" and "2" could be "pretty printed" as:

  name="list",addr="0x7fffb3245f80",
  value="<3 items>",type="std::list<std::string>",
(Continue reading)

Permalink | Reply | 18 comments |
headers
Tom Tromey | 1 Oct 2008 21:19
Picon
Favicon

Re: pretty-printing update

>>>>> "André" == André Pönitz <apoenitz@...> writes:

André> For  a "machine" interface, something more structured (and more
André> robust to parse) would be needed anyway.

We talked about this at the meeting.

In my email I didn't mention it, but there is already code on the
python branch to handle pretty-printing for MI.  This code works in a
somewhat different way than the CLI pretty-printing I've implemented.

One thing on my to-do list is to look at unifying the two.  It would
be nice for library authors (e.g.) to be able to write a single class
for printing a type and have it work in all cases.

Currently I think this will involve changes to both cases.

Right now the MI code relies on the MI consumer (GUI or whatever) to
sent "var-set-format" with the name of a type and the name of a
formatter class.

I think it would be fine to keep this, but I'd prefer the default
setup to be less client-specific.  Instead I think the print class
should be specified by python code, and this should (typically) happen
when an objfile is opened.

That is: user program loads libstdc++, gdb looks in libstdc++ install
directory (or separate debug info directory) for python code, then
that python code registers printers.
(Continue reading)

Permalink | Reply | 17 comments |
headers
André Pönitz | 2 Oct 2008 09:39

Re: pretty-printing update

On Wednesday 01 October 2008 21:19:39 Tom Tromey wrote:
> >>>>> "André" == André Pönitz <apoenitz@...> writes:
> 
> André> For  a "machine" interface, something more structured (and more
> André> robust to parse) would be needed anyway.
> 
> We talked about this at the meeting.

Ah ;-)

> In my email I didn't mention it, but there is already code on the
> python branch to handle pretty-printing for MI.  This code works in a
> somewhat different way than the CLI pretty-printing I've implemented.
> 
> One thing on my to-do list is to look at unifying the two.  It would
> be nice for library authors (e.g.) to be able to write a single class
> for printing a type and have it work in all cases.
>
> Currently I think this will involve changes to both cases.
> 
> Right now the MI code relies on the MI consumer (GUI or whatever) to
> sent "var-set-format" with the name of a type and the name of a
> formatter class.
>
> I think it would be fine to keep this, but I'd prefer the default
> setup to be less client-specific.  

Well, I feel the opposite. See below.

> Instead I think the print class
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tom Tromey | 2 Oct 2008 17:01
Picon
Favicon

Re: pretty-printing update

>>>>> "André" == André Pönitz <apoenitz@...> writes:

André> But from a GUI point of view there is not really much
André> difference whether gdb automatically looks in certain places
André> for custom formatters or whether it has to pump a few hundred
André> lines of "-var-set-format" into gdb "manually".

I think the problem here is naming of the formatters.  Suppose we have
a custom formatters for a large number of libraries -- say one for
every C++ library in the OS.  How would a front end know the names of
the various formatters to supply?

The nice thing about the auto-loading plan is that it means that
library authors can maintain formatting bits independently.

André> Actually I would argue that the formatter code is pretty likely
André> to depend more on the actual GUI than on the type (even with
André> changing libstdc++ in mind). In the example I gave there are
André> fields like "name" and "valueencoded" that will probably only
André> make sense to a very specific GUI.

I see what you mean.  I think the current MI code on this branch just
emits a couple of known fields.  Maybe that is insufficient -- I don't
know yet.

Tom
Permalink | Reply | 0 comments |
headers
Tom Tromey | 2 Oct 2008 17:06
Picon
Favicon

Re: pretty-printing update

>>>>> "Tom" == Tom Tromey <tromey@...> writes:

Tom> (gdb) p intmap
Tom> $2 = number of elements = 2
Tom> [5] = 0x804c057 "liver"
Tom> [23] = 0x804c046 "maude"

Tom> The internal problem is that the value-printing code does not know
Tom> that gdb printed "$2 = ".

FYI, I implemented a quick fix for this.  Now the pretty-printer will
indent subsequent lines according to the indentation where it started:

(gdb) p intmap
$1 = std::map with 2 elements
     [5] = 0x804c277 "liver"
     [23] = 0x804c266 "maude"

I think this looks pretty good.  It also looks ok inside structures:

(gdb) p val
$1 = {
  x = [0] = 23
      [1] = 24
      [2] = 25, 
  s = 0x804e03c "maude"
}

Tom
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vladimir Prus | 2 Oct 2008 18:16

Re: pretty-printing update

Tom Tromey wrote:

>>>>>> "André" == André Pönitz <apoenitz@...> writes:
> 
> André> For  a "machine" interface, something more structured (and more
> André> robust to parse) would be needed anyway.
> 
> We talked about this at the meeting.
> 
> In my email I didn't mention it, but there is already code on the
> python branch to handle pretty-printing for MI.  This code works in a
> somewhat different way than the CLI pretty-printing I've implemented.
> 
> One thing on my to-do list is to look at unifying the two.  It would
> be nice for library authors (e.g.) to be able to write a single class
> for printing a type and have it work in all cases.

I think the most fundamental difference between your approach and
MI one is that for MI, there's class with one method to return
string rendition, and another method to return children values.
Returning children values, as opposed to some string names, is
very desirable for MI. OTOH, there's no support to specify names
for children, they are just numbered. Also, for std::map, you
probably would want to return pairs of values and GUI should understand
that mapping is been displayed, I don't know how to communicate this.

Note also in MI, each variable object is associated with an instance
of a class, so it can keep some state. I was also thinking that the
method returning children should actually return an interator 
(use yield), so that incremental fetch of children is possible.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Sami Wagiaalla | 3 Oct 2008 18:03
Picon
Favicon

Re: pretty-printing update


> I've appended my sample printers.  These print a number of objects
> defined in libstdc++.
> 

How do I install these printers ?

> If you want to try it, all the code is on archer-tromey-python.
> 

I am getting build warnings:
cc1: warnings being treated as errors
../../gdb/printcmd.c: In function ‘x_command’:
../../gdb/printcmd.c:1237: error: ‘fmt.raw’ may be used uninitialized in 
this function
../../gdb/printcmd.c: In function ‘display_command’:
../../gdb/printcmd.c:1313: error: ‘fmt.raw’ may be used uninitialized in 
this function
../../gdb/printcmd.c: In function ‘output_command’:
../../gdb/printcmd.c:955: error: ‘fmt.raw’ may be used uninitialized in 
this function

Sami
Permalink | Reply | 2 comments |
headers
Tom Tromey | 3 Oct 2008 19:49
Picon
Favicon

Re: pretty-printing update

>> I've appended my sample printers.  These print a number of objects
>> defined in libstdc++.

Sami> How do I install these printers ?

I'm using:

    python execfile ('/home/tromey/gnu/python-gdb/libcxx.py')

I haven't tried the auto-loading stuff yet.

Sami> I am getting build warnings:

Thanks.  I pushed a fix for these.

Tom
Permalink | Reply | 1 comment |
headers
Tom Tromey | 3 Oct 2008 20:13
Picon
Favicon

Re: pretty-printing update

Tom> The other problem is that, right now, pretty-printing of fields is not
Tom> disabled by '/r'.  This is because I didn't make a pass through all
Tom> the val_print hierarchy, adding a 'raw' argument.  This code is a
Tom> mish-mash of arguments and globals, and I'm considering refactoring
Tom> the mess so that we pass around a single format-controlling struct
Tom> instead.

On the branch, I hacked around this with a new global.

I have a patch to redo all the printing functions to take a print
options structure -- but it is large and I think I'd prefer to try to
get it in upstream first.  My reasoning is that I'd rather avoid
carrying a huge divergence for something that is rather peripheral.

Tom
Permalink | Reply | 0 comments |

Gmane