From: "Doug Evans" <dje@google.com>
To: "Nick Roberts" <nickrob@snap.net.nz>
Cc: "Vladimir Prus" <ghost@cs.msu.su>, gdb-patches@sources.redhat.com
Subject: Re: [RFC] Variable objects for STL containers
Date: Sun, 17 Feb 2008 21:57:00 -0000 [thread overview]
Message-ID: <e394668d0802171357s7224cb1h3448ac3565e84c8@mail.gmail.com> (raw)
In-Reply-To: <18360.38522.477967.328610@kahikatea.snap.net.nz>
On Feb 17, 2008 12:18 PM, Nick Roberts <nickrob@snap.net.nz> wrote:
>
> I think for lists, maps etc, Gdb needs to traverse the internal data structure
> each to see if there are new elements or if any have been deleted. This need
> only be done when execution stops, of course, but I guess it could be expensive
> for stepping.
>
> The ideas here are just for discussion and I'm more than happy to look at any
> changes you might like to make.
There's something I don't understand, and maybe you can help clear
things up. It seems like this approach is going down a path of
hardwiring a lot of knowledge into gdb. Solving this just for STL
(and then only one version of STL) seems to be one piece of a general
problem, why pick an unscalable solution? If the knowledge was in a
collection of dlopen'd .so (or some such), and users could provide
more, then that might be reasonable. [Setting aside use of python for
this, I understand there is some pushback to going that route. It'd
be cool if the python support used the same interface, then one could
have it both ways. The python support is, of course, not just for
this and one wouldn't want python to plug into gdb in a piecemeal
fashion. OTOH, if a clean solution could be found that let one solve
this with either C[/C++] or python then that might be very useful.]
next prev parent reply other threads:[~2008-02-17 21:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-13 3:33 Nick Roberts
2008-02-15 14:29 ` Marc Khouzam
2008-02-15 14:42 ` Daniel Jacobowitz
2008-02-15 21:57 ` Nick Roberts
2008-02-17 13:36 ` Vladimir Prus
2008-02-17 20:18 ` Nick Roberts
2008-02-17 21:57 ` Doug Evans [this message]
2008-02-17 22:27 ` Nick Roberts
2008-02-26 2:34 ` Daniel Jacobowitz
2008-02-18 7:45 ` Vladimir Prus
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=e394668d0802171357s7224cb1h3448ac3565e84c8@mail.gmail.com \
--to=dje@google.com \
--cc=gdb-patches@sources.redhat.com \
--cc=ghost@cs.msu.su \
--cc=nickrob@snap.net.nz \
/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