This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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?)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]