This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: extending Gdb to display app specific data
bstell@ix.netcom.com writes:
> Thanks.
>
> These are both good ideas which I will pursue.
Also, if you let us know what datatypes you are specifically referring
to, we can help.
For instance, c++ vectors (maps broke recently, i'm working on it),
you can use gdb convenience variables and iterators,
like
set $a = ourVector.begin()
print *$a
print *$a++
etc
It'll print the right thing, calling the right functions, etc.
Same with
print ourVector[0].
It'll call operator[] properly, and print the result.
As soon as i fix maps, you'll be able to do the same
print ourMap["hello"]
C++ strings vary in representation, but we could always make it call
.c_str() when you print it, or something.
Then you run into the problem that people debugging c++ standard
libraries won't be able to view the internals of their strings.
--Dan
>
> Daniel Berlin wrote:
> > Um, use a single routine name, overloaded for the
> > data types you want to print?
> > You did say you were using C++, right?
>
> Eli Zaretskii wrote:
> > The function (from the debugged program) that is used to print the
> > data type could find out the type itself. That's what `debug_print'
> > in Emacs does, albeit indirectly.
>
> (Fernando, can we use this in the Insight tooltips/bubbles?)