dejagnu

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
>