casting in gdb

casting in gdb

[Jacques Le Normand]

 That explains alot, thanks
 Would you know how to tell g++ to keep all the methods, even when they're
 not used?
 Say I have a map<string,int> m, how would I get gdb to display m["foo"] ?
It
 gives me the silly "function expects something else" error, which I can
 understand since gdb won't cast from char* to string. I'm guessing I need
to
 define my own subroutines.
 --Jacques
> ----- Original Message -----
> From: "Daniel Jacobowitz" <drow@mvista.com>
> To: "Jacques Le Normand" <jacqueslen@sympatico.ca>
> Cc: "Daniel Berlin" <dberlin@dberlin.org>; <gdb@sources.redhat.com>
> Sent: Saturday, December 14, 2002 2:35 AM
> Subject: Re: casting in gdb
>
>
> > On Fri, Dec 13, 2002 at 02:43:17PM -0500, Jacques Le Normand wrote:
> > > here you go, thanks for lending a hand...
> > >
> > > [countchocula@chocoland countchocula]$ g++ -ggdb test.cpp -o test.o
> > > [countchocula@chocoland countchocula]$ gdb test.o
> > > GNU gdb Red Hat Linux (5.2.1-4)
> > > Copyright 2002 Free Software Foundation, Inc.
> > > GDB is free software, covered by the GNU General Public License, and
you
> are
> > > welcome to change it and/or distribute copies of it under certain
> > > conditions.
> > > Type "show copying" to see the conditions.
> > > There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> > > This GDB was configured as "i386-redhat-linux"...
> > > (gdb) b 10
> > > Breakpoint 1 at 0x80486f5: file test.cpp, line 10.
> > > (gdb) r
> > > Starting program: /home/countchocula/test.o
> > >
> > > Breakpoint 1, main () at test.cpp:10
> > > 10        a.push_back(2);
> > > (gdb) p a[0]
> > > One of the arguments you tried to pass to operator[] could not be
> converted
> > > to w
> > > hat the function wants.
> > > (gdb)
> >
> > This one's pretty simple once you figure it out.  The error message is
> > really bad; I'll hold on to this and try to improve it.
> >
> > Your program doesn't _use_ operator[].  So it doesn't get compiled into
> > the program, and GDB can't call it to figure out what to do.
> >
> > What happens if you add a call to the operator?
> >
> > [I noticed some other quirks; for instance, if your program only uses
> > the mutable version and GDB finds the const version first, it may get
> > confused...]
> >
> > --
> > Daniel Jacobowitz
> > MontaVista Software                         Debian GNU/Linux Developer
> >
>

Re: casting in gdb

[Daniel Jacobowitz]

On Sat, Dec 14, 2002 at 10:49:46PM -0500, Jacques Le Normand wrote:
> 
> 
> 
>  That explains alot, thanks
>  Would you know how to tell g++ to keep all the methods, even when they're
>  not used?

You can't; you've gotta add a dummy function which uses them, or
explicitly instantiate them.

>  Say I have a map<string,int> m, how would I get gdb to display m["foo"] ?
> It
>  gives me the silly "function expects something else" error, which I can
>  understand since gdb won't cast from char* to string. I'm guessing I need
> to
>  define my own subroutines.

Pretty much.  Some day you GDB may do this for you but it doesn't right
now.

>  --Jacques
> > ----- Original Message -----
> > From: "Daniel Jacobowitz" <drow@mvista.com>
> > To: "Jacques Le Normand" <jacqueslen@sympatico.ca>
> > Cc: "Daniel Berlin" <dberlin@dberlin.org>; <gdb@sources.redhat.com>
> > Sent: Saturday, December 14, 2002 2:35 AM
> > Subject: Re: casting in gdb
> >
> >
> > > On Fri, Dec 13, 2002 at 02:43:17PM -0500, Jacques Le Normand wrote:
> > > > here you go, thanks for lending a hand...
> > > >
> > > > [countchocula@chocoland countchocula]$ g++ -ggdb test.cpp -o test.o
> > > > [countchocula@chocoland countchocula]$ gdb test.o
> > > > GNU gdb Red Hat Linux (5.2.1-4)
> > > > Copyright 2002 Free Software Foundation, Inc.
> > > > GDB is free software, covered by the GNU General Public License, and
> you
> > are
> > > > welcome to change it and/or distribute copies of it under certain
> > > > conditions.
> > > > Type "show copying" to see the conditions.
> > > > There is absolutely no warranty for GDB.  Type "show warranty" for
> > details.
> > > > This GDB was configured as "i386-redhat-linux"...
> > > > (gdb) b 10
> > > > Breakpoint 1 at 0x80486f5: file test.cpp, line 10.
> > > > (gdb) r
> > > > Starting program: /home/countchocula/test.o
> > > >
> > > > Breakpoint 1, main () at test.cpp:10
> > > > 10        a.push_back(2);
> > > > (gdb) p a[0]
> > > > One of the arguments you tried to pass to operator[] could not be
> > converted
> > > > to w
> > > > hat the function wants.
> > > > (gdb)
> > >
> > > This one's pretty simple once you figure it out.  The error message is
> > > really bad; I'll hold on to this and try to improve it.
> > >
> > > Your program doesn't _use_ operator[].  So it doesn't get compiled into
> > > the program, and GDB can't call it to figure out what to do.
> > >
> > > What happens if you add a call to the operator?
> > >
> > > [I noticed some other quirks; for instance, if your program only uses
> > > the mutable version and GDB finds the const version first, it may get
> > > confused...]
> > >
> > > --
> > > Daniel Jacobowitz
> > > MontaVista Software                         Debian GNU/Linux Developer
> > >
> >
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: casting in gdb

[Jim Ingham]

David,

For ObjC, where getting to the real data of an object is sometimes 
highly non-trivial, we used method calls in the inferior.  We insert a 
shared library into the inferior process when we launch it.  This 
shared library has functions that produce a user-friendly view of the 
object passed to them and stuff it somewhere in inferior memory.  Then 
a client (PB in our case) can read out this memory and show that to the 
user.

However, for STL classes the job is a little easier, since you can 
mostly get what you want from presenting various members of the class 
(or one of its sub-classes), perhaps with appropriate casts.  For this 
case, we were planning to do something more like what Visual Studio or 
CodeWarrior do.  Both of these allow users to associate some custom 
printing description with a given type.  CW & VS use an XML description 
file giving what members to print - and what cast operation to apply to 
the members - for a given C++ type.  This is faster than the ObjC 
method, since it does not involve inferior function calls, so where it 
is possible to use something like this it is preferable.

We haven't gotten past the investigation of what CW & VC++ do, and I am 
not sure yet whether we will implement this in gdb, or let PB drive. So 
what we end up doing may or may not be interesting to the gdb 
community.  PB already has an XML parser, and the facilities to manage 
this sort of thing, so it is more natural for us to do it there.

Jim


On Thursday, January 16, 2003, at 04:54  AM, 
gdb-digest-help@sources.redhat.com wrote:

> On Sat, 14 Dec 2002 23:47:42 -0600, Michael Elizabeth Chastain 
> <mec@shout.net> said:
>
>> I'm playing with the idea that gdb should know more about the C++
>> standard library types, in the same spirit that gdb knows that a C
>> "char *" usually points to a string terminated with '\0'.  I would
>> like gdb to understood more about std::string, std::vector, std:map,
>> and so on.
>
> I was going through my old messages, and I noticed this one.  For what
> it's worth, Apple has implemented something like this for strings in
> Objective C, where they actually print out the string in question, and
> they say it works pretty well.  Apparently the implementation of
> strings is complicated enough that they really didn't want to tie it
> to the implementation; so GDB prints out Objective C strings by
> actually doing the method call.
>
> Of course, the above message was part of a thread that noted that, in
> C++, the appropriate methods might not be compiled in.  That's a real
> problem; I'm not sure what to do about that.
>
> David Carlton
> carlton@math.stanford.edu
>
--
Jim Ingham                                   jingham@apple.com
Developer Tools
Apple Computer

Re: casting in gdb

[David Carlton]

On Sat, 14 Dec 2002 23:47:42 -0600, Michael Elizabeth Chastain <mec@shout.net> said:

> I'm playing with the idea that gdb should know more about the C++
> standard library types, in the same spirit that gdb knows that a C
> "char *" usually points to a string terminated with '\0'.  I would
> like gdb to understood more about std::string, std::vector, std:map,
> and so on.

I was going through my old messages, and I noticed this one.  For what
it's worth, Apple has implemented something like this for strings in
Objective C, where they actually print out the string in question, and
they say it works pretty well.  Apparently the implementation of
strings is complicated enough that they really didn't want to tie it
to the implementation; so GDB prints out Objective C strings by
actually doing the method call.

Of course, the above message was part of a thread that noted that, in
C++, the appropriate methods might not be compiled in.  That's a real
problem; I'm not sure what to do about that.

David Carlton
carlton@math.stanford.edu

Re: casting in gdb

[Daniel Jacobowitz]

On Sat, Dec 14, 2002 at 11:47:42PM -0600, Michael Elizabeth Chastain wrote:
> I'm playing with the idea that gdb should know more about the C++
> standard library types, in the same spirit that gdb knows that a C "char
> *" usually points to a string terminated with '\0'.  I would like gdb
> to understood more about std::string, std::vector, std:map, and so on.
> 
> Daniel J, what do you think?

I think there's a pretty big problem with approaching the problem from
this side.  You can't do it by teaching GDB more about the _types_. 
You have to teach it more about the _implementation_.  i.e. every time
you do this it is tied to a particular STL implementation.

I'm not saying that it's a bad idea, just that you need to look at it
from the other side first.

That said, we need generic facilities for target-specific type handling;
that would be really nice.  Do we care that this means "MyVector[0]"
will make a function call and "std::vector[0]" won't?  I don't think we
will.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: casting in gdb

[Jacques Le Normand]

absolutely!
I'm currently starting to write an elisp gdb front-end that will translate
directives so that gdb can understand them. Hewever this apprach is
implementation dependant (both for gdb and gcc) and will only work for the
stl. Doing this would not only make my job easier, but more scalable.
However, I wonder if enough information is given to gdb to be able to
non-deterministically cast. I am a gdb newbie, but if unused methods are
given the chop by g++, then how will gdb be able to cast with
string::string(char*) if we decide not to use the constructor? Or would gdb
know how to cast to/from all stl objects?
--Jacques
----- Original Message -----
From: "Michael Elizabeth Chastain" <mec@shout.net>
To: <drow@mvista.com>; <jacqueslen@sympatico.ca>
Cc: <gdb@sources.redhat.com>
Sent: Sunday, December 15, 2002 12:47 AM
Subject: Re: casting in gdb


> I'm playing with the idea that gdb should know more about the C++
> standard library types, in the same spirit that gdb knows that a C "char
> *" usually points to a string terminated with '\0'.  I would like gdb
> to understood more about std::string, std::vector, std:map, and so on.
>
> Daniel J, what do you think?
>
> Michael C
>

Re: casting in gdb

[Michael Elizabeth Chastain]

I'm playing with the idea that gdb should know more about the C++
standard library types, in the same spirit that gdb knows that a C "char
*" usually points to a string terminated with '\0'.  I would like gdb
to understood more about std::string, std::vector, std:map, and so on.

Daniel J, what do you think?

Michael C

Re: casting in gdb

[Daniel Berlin]

On Sat, 14 Dec 2002, Daniel Jacobowitz wrote:

> On Fri, Dec 13, 2002 at 02:43:17PM -0500, Jacques Le Normand wrote:
> > here you go, thanks for lending a hand...
> >
> > [countchocula@chocoland countchocula]$ g++ -ggdb test.cpp -o test.o
> > [countchocula@chocoland countchocula]$ gdb test.o
> > GNU gdb Red Hat Linux (5.2.1-4)
> > Copyright 2002 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for details.
> > This GDB was configured as "i386-redhat-linux"...
> > (gdb) b 10
> > Breakpoint 1 at 0x80486f5: file test.cpp, line 10.
> > (gdb) r
> > Starting program: /home/countchocula/test.o
> >
> > Breakpoint 1, main () at test.cpp:10
> > 10        a.push_back(2);
> > (gdb) p a[0]
> > One of the arguments you tried to pass to operator[] could not be converted
> > to w
> > hat the function wants.
> > (gdb)
>
> This one's pretty simple once you figure it out.  The error message is
> really bad; I'll hold on to this and try to improve it.
Hey now
I added that error message, because it was horrible before that.
Ahh, here we go:
2542c2542
<       error ("Argument list of %s mismatch with component in the
structure.", name);
---
>       error ("One of the arguments you tried to pass to %s could not be
converted to what the function wants.", name);


I remember i had a patch that added a seperate error message for the case
where the operator wasn't existing, but it's quite invasive.
Look at where that error message pops up.
You'll note you'd need to make search_struct_method take another argument
so we can tell if we couldn't *find* it, or we had a mismatch.


>
> Your program doesn't _use_ operator[].  So it doesn't get compiled into
> the program, and GDB can't call it to figure out what to do.
>
> What happens if you add a call to the operator?
>
> [I noticed some other quirks; for instance, if your program only uses
> the mutable version and GDB finds the const version first, it may get
> confused...]
>
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
>

Re: casting in gdb

[Daniel Jacobowitz]

On Fri, Dec 13, 2002 at 02:43:17PM -0500, Jacques Le Normand wrote:
> here you go, thanks for lending a hand...
> 
> [countchocula@chocoland countchocula]$ g++ -ggdb test.cpp -o test.o
> [countchocula@chocoland countchocula]$ gdb test.o
> GNU gdb Red Hat Linux (5.2.1-4)
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-redhat-linux"...
> (gdb) b 10
> Breakpoint 1 at 0x80486f5: file test.cpp, line 10.
> (gdb) r
> Starting program: /home/countchocula/test.o
> 
> Breakpoint 1, main () at test.cpp:10
> 10        a.push_back(2);
> (gdb) p a[0]
> One of the arguments you tried to pass to operator[] could not be converted
> to w
> hat the function wants.
> (gdb)

This one's pretty simple once you figure it out.  The error message is
really bad; I'll hold on to this and try to improve it.

Your program doesn't _use_ operator[].  So it doesn't get compiled into
the program, and GDB can't call it to figure out what to do.

What happens if you add a call to the operator?

[I noticed some other quirks; for instance, if your program only uses
the mutable version and GDB finds the const version first, it may get
confused...]

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

casting in gdb

[Jacques Le Normand]

how do you get gdb to cast to size_t?
I realize that size_t is a typedef to unsigned long long or somesuch.
A little background:
when I'm debugging my vector<int> v, gdb won't let me type v[0], instead =
it says this: "One of the arguments you tried to pass to operator[] =
could not be converted to what the funtion wants."
I then looked up what operator[] took in the sgi docs and it said a =
size_t. Anyone have any ideas?
(I realize I can do p *(v._M_start+n) , but having a method for casting =
would help me later on)
--Jacques