public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Ian Lance Taylor <iant@google.com>
To: Tom Tromey <tromey@redhat.com>
Cc: Daniel Jacobowitz <drow@false.org>, Frysk List <frysk@sourceware.org>
Subject: Re: Roadmap beginnings
Date: Mon, 14 Jul 2008 17:19:00 -0000	[thread overview]
Message-ID: <m3r69wz8n6.fsf@google.com> (raw)
In-Reply-To: <m3hcas8lxv.fsf@fleche.redhat.com> (Tom Tromey's message of "Mon\, 14 Jul 2008 10\:33\:48 -0600")

Tom Tromey <tromey@redhat.com> writes:

> Tom> * Correct expression parsing.  (Though I am told this is extremely
> Tom> difficult to impossible in the general case.)
>
> Daniel> It does a not half bad job, and specific problems with it are fixable.
> Daniel> As for ultimate correctness and completeness, I have serious doubts
> Daniel> that it is feasible - and I also doubt it would see enough use to
> Daniel> justify the enormous investment.  Prove me wrong and we'll merge it :-)
>
> :).  I'm looking around a bit to see if I can find specifics of what
> is wrong.

I don't know if this counts as "expression parsing," but the most
obvious problems that I encounter are the difficulties in working with
STL objects.  Given "std::vector<T> v", I can't do "print v[0]".
Given "std::vector<T>::iterator p", I can't do "print *p".  That is
minimal required functionality for good C++ debugging.  This needs to
work smoothly for STL types and for user defined types.

It would also be nice if gdb could do template parameter defaulting,
although that is rather less important as tab completion can take care
of it.

A related problem, which I don't know how to solve, is that many
simple C++ accessors get inlined, and are not available when
debugging.  This makes it vastly more difficult to debug optimized C++
programs (indeed, this problem is more serious for me in practice than
the debuginfo problems discussed at the summit).

Ian

  parent reply	other threads:[~2008-07-14 17:19 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-11 19:53 Tom Tromey
2008-07-11 20:56 ` Jan Kratochvil
2008-07-11 21:37   ` Tom Tromey
2008-07-11 21:54     ` Daniel Jacobowitz
2008-07-11 23:11   ` Kris Van Hees
2008-07-11 21:53 ` Daniel Jacobowitz
2008-07-14 16:34   ` Tom Tromey
2008-07-14 16:45     ` Daniel Jacobowitz
2008-07-14 16:58       ` Phil Muldoon
2008-07-14 17:09         ` Daniel Jacobowitz
2008-07-14 17:19     ` Ian Lance Taylor [this message]
2008-07-14 17:34       ` Daniel Jacobowitz
2008-07-14 18:04         ` Tom Tromey
2008-07-14 18:12           ` Daniel Jacobowitz
2008-07-14 18:11         ` Ian Lance Taylor
2008-07-14 17:35       ` Tom Tromey
2008-07-14 18:13         ` Ian Lance Taylor
2008-07-22 20:29   ` Debugger Work (Was: Roadmap beginnings) Tom Tromey
2008-07-11 22:48 ` Roadmap beginnings Phil Muldoon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3r69wz8n6.fsf@google.com \
    --to=iant@google.com \
    --cc=drow@false.org \
    --cc=frysk@sourceware.org \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).