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

[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

[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

[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

[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

dejagnu

[bemis]

where does gdb get dejagnu?
I have recently placed an xml patch in dejagnu, and I am not seeing it
when I do a toolchain build.
-matt bemis

Re: dejagnu

[Andrew Cagney]

> where does gdb get dejagnu?
> I have recently placed an xml patch in dejagnu, and I am not seeing it
> when I do a toolchain build.
> -matt bemis

As a convenience, the GDB repository also includes a version of dejagnu. 
   However, if you only check out the `gdb' module (instead of the 
gdb+dejagnu module) or even simply rename the dejagnu directory, the 
installed version with the xml patches will be used.

Someone might even do a re-sync.

Andrew

Re: dejagnu

[Fernando Nasser]

Andrew Cagney wrote:>> where does gdb get dejagnu?
>> I have recently placed an xml patch in dejagnu, and I am not seeing it
>> when I do a toolchain build.
>> -matt bemis
> 
> 
> As a convenience, the GDB repository also includes a version of dejagnu. 
>   However, if you only check out the `gdb' module (instead of the 
> gdb+dejagnu module) or even simply rename the dejagnu directory, the 
> installed version with the xml patches will be used.
> 
> Someone might even do a re-sync.
> 

It was done.  Our copy has XML since I did it shortly after it was released by 
Rob. And Nick has included Dejagnu in his merges now.

This looks like old sources...


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: dejagnu

[bemis]

I placed a new patch in GDB shortly after the 1.4.3 release. So my patch
is in the latest dejagnu.  If I send you a patch for 1.4.3 would you
include it in your version of dejagnu???...then the -x switch would work
properly.

On Thu, 2002-12-05 at 19:26, Fernando Nasser wrote:
> Andrew Cagney wrote:>> where does gdb get dejagnu?
> >> I have recently placed an xml patch in dejagnu, and I am not seeing it
> >> when I do a toolchain build.
> >> -matt bemis
> > 
> > 
> > As a convenience, the GDB repository also includes a version of dejagnu. 
> >   However, if you only check out the `gdb' module (instead of the 
> > gdb+dejagnu module) or even simply rename the dejagnu directory, the 
> > installed version with the xml patches will be used.
> > 
> > Someone might even do a re-sync.
> > 
> 
> It was done.  Our copy has XML since I did it shortly after it was released by 
> Rob. And Nick has included Dejagnu in his merges now.
> 
> This looks like old sources...
> 
> 
> -- 
> Fernando Nasser
> Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9

Re: dejagnu

[Fernando Nasser]

bemis wrote:> I placed a new patch in GDB shortly after the 1.4.3 release. So my 
patch
> is in the latest dejagnu.  If I send you a patch for 1.4.3 would you
> include it in your version of dejagnu???...then the -x switch would work
> properly.
  ^^^^^^^^^

Ah!  It it is there, but needs a fix, is that what you are trying to say?

Of course, if Rob accepted it already we will do the same.  I will check with 
Rob if he plans to release a 1.4.4 and do a full merge if that is the case.

Regards,
Fernando

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: dejagnu

[Rob Savoye]

On Thu, Dec 05, 2002 at 08:08:45PM -0500, Fernando Nasser wrote:

> Ah!  It it is there, but needs a fix, is that what you are trying to say?

> Of course, if Rob accepted it already we will do the same.  I will check with 
> Rob if he plans to release a 1.4.4 and do a full merge if that is the case.

  The XML support is in the existing 1.4.3 release, but yeah, when this
current round of XML hacking is done, I guess I can do another release. It'll
be in CVS on subversions too before then. 

	- rob -

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

Re: *****SPAM***** casting in gdb

[Daniel Berlin]

On Friday, December 13, 2002, at 01:28  AM, Jacques Le Normand wrote:

> 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
>
While this doesn't help *you*, it should help the current C++ people 
for GDB:
I've seen this with STABS debugging info when some of the operator 
functions were left out of the debugging info, but others weren't (GCC 
+ STABS will omit unused functions from debug info), and we ommitted 
the operator we really need to use, and in some cases when we parsed 
the types of the arguments out of the demangled function name and come 
up with some weird type.
>

Re: *****SPAM***** casting in gdb

[Daniel Jacobowitz]

On Fri, Dec 13, 2002 at 10:33:02AM -0500, Daniel Berlin wrote:
> 
> On Friday, December 13, 2002, at 01:28  AM, Jacques Le Normand wrote:
> 
> >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
> >
> While this doesn't help *you*, it should help the current C++ people 
> for GDB:
> I've seen this with STABS debugging info when some of the operator 
> functions were left out of the debugging info, but others weren't (GCC 
> + STABS will omit unused functions from debug info), and we ommitted 
> the operator we really need to use, and in some cases when we parsed 
> the types of the arguments out of the demangled function name and come 
> up with some weird type.

Yeah, something like that's my guess; I've been getting this better but
it's taking time...

Jacques, could you do me a favor?  Try to create a small test case for
the error message using vector.

The problem is almost certainly that the argument 'this' to the
operator is of the wrong type, not that the integer is of the wrong
type.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: *****SPAM***** casting in gdb

[Jacques Le Normand]

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)


the code
#include <vector>
using namespace std;
int main(){
  vector<int> a;
  a.push_back(2);
  a.push_back(2);
  a.push_back(2);
  a.push_back(2);
  a.push_back(2);
  a.push_back(2);
  a.push_back(2);
  a.push_back(2);
  a.push_back(2);
  a.push_back(2);
  a.push_back(2);
  a.push_back(2);
  a.push_back(2);
  a.push_back(2);
  a.push_back(2);
  a.push_back(2);
  a.push_back(2);
  return 0;
}


----- Original Message -----
From: "Daniel Jacobowitz" <drow@mvista.com>
To: "Daniel Berlin" <dberlin@dberlin.org>
Cc: "Jacques Le Normand" <jacqueslen@sympatico.ca>; <gdb@sources.redhat.com>
Sent: Friday, December 13, 2002 11:47 AM
Subject: Re: *****SPAM***** casting in gdb


> On Fri, Dec 13, 2002 at 10:33:02AM -0500, Daniel Berlin wrote:
> >
> > On Friday, December 13, 2002, at 01:28  AM, Jacques Le Normand wrote:
> >
> > >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
> > >
> > While this doesn't help *you*, it should help the current C++ people
> > for GDB:
> > I've seen this with STABS debugging info when some of the operator
> > functions were left out of the debugging info, but others weren't (GCC
> > + STABS will omit unused functions from debug info), and we ommitted
> > the operator we really need to use, and in some cases when we parsed
> > the types of the arguments out of the demangled function name and come
> > up with some weird type.
>
> Yeah, something like that's my guess; I've been getting this better but
> it's taking time...
>
> Jacques, could you do me a favor?  Try to create a small test case for
> the error message using vector.
>
> The problem is almost certainly that the argument 'this' to the
> operator is of the wrong type, not that the integer is of the wrong
> type.
>
> --
> 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

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
>