Re: I can't stand it any more.

[Daniel Berlin <dberlin@redhat.com>]

> > That, and the 13 other bugs in the bug
> > database, are all unassigned.
>
> Why are you emailing gdb@sources about redhat gdb bugs?

It just occurred to me that you were referring to gdb's bug database.
Forgot we had one. Got confused when you said "generic redhat development
environment".

Let's try both your examples over on this puter:
Breakpoint 1, main () at temp.cc:4
4       cout <<1<<endl;
(gdb) p cout << 1
$1 = (ostream &) @0x1810920: {<ios> = {<_ios_fields> = {_strbuf =
0x17dea78,
      _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000',
      _exceptions = 0 '\000', _precision = 6, _arrays = 0x0},
    _vptr.ios = 0x0}, _vb.3ios = 0x1810924}
(gdb) p cout << "A string"
$2 = (ostream &) @0x1810920: {<ios> = {<_ios_fields> = {_strbuf =
0x17dea78,
      _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000',
      _exceptions = 0 '\000', _precision = 6, _arrays = 0x0},
    _vptr.ios = 0x0}, _vb.3ios = 0x1810924}
(gdb) p endl(cout)
1A string
$3 = (ostream &) @0x1810920: {<ios> = {<_ios_fields> = {_strbuf =
0x17dea78,
      _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000',
      _exceptions = 0 '\000', _precision = 6, _arrays = 0x0},
    _vptr.ios = 0x0}, _vb.ios = 0x1810924}
(gdb)

Looks fine from here.
Of course, this is a ppc.

Let's try an x86
:
GNU gdb 5.0
Copyright 2000 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 "i686-pc-linux"...
(gdb) p cout << 1
$1 = 0
(gdb) p cout << "A string"
evaluation of this expression requires the target program to be active
(gdb) b main
Breakpoint 1 at 0x8048672: file temp.cc, line 4.
(gdb) r
Starting program: /home/dberlin/./a.out

Breakpoint 1, main () at temp.cc:4
4       cout <<1<<endl;
(gdb) p cout << 1
$2 = (ostream &) @0x8049830: {<ios> = {<_ios_fields> = {_strbuf =
0x40065760,
      _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000',
      _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr. =
0x0},
  _vb.ios = 0x8049834}
(gdb) p cout << "A string"
$3 = (ostream &) @0x8049830: {<ios> = {<_ios_fields> = {_strbuf =
0x40065760,
      _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000',
      _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr. =
0x0},
  _vb.ios = 0x8049834}
(gdb) p endl(cout)
132544
$4 = (ostream &) @0x8049830: {<ios> = {<_ios_fields> = {_strbuf =
0x40065760,
      _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000',
      _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr. =
0x0},
  _vb.ios = 0x8049834}
(gdb)

Hmmm.
Looks like we didn't push the pointer right or something.
But the 1 is valid.
(gdb) p endl(cout)
32560
$8 = (ostream &) @0x8049830: {<ios> = {<_ios_fields> = {_strbuf =
0x40065760,
      _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000',
      _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr. =
0x0},
  _vb.ios = 0x8049834}
(gdb) p endl(cout)

$9 = (ostream &) @0x8049830: {<ios> = {<_ios_fields> = {_strbuf =
0x40065760,
      _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000',
      _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr. =
0x0},
  _vb.ios = 0x8049834}
(gdb) p cout << "a"
$10 = (ostream &) @0x8049830: {<ios> = {<_ios_fields> = {_strbuf =
0x40065760,
      _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000',
      _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr. =
0x0},
  _vb.ios = 0x8049834}
(gdb) p endl(cout)
32568
$11 = (ostream &) @0x8049830: {<ios> = {<_ios_fields> = {_strbuf =
0x40065760,
      _tie = 0x0, _width = 0, _flags = 17, _fill = 32, _state = 0 '\000',
      _exceptions = 0 '\000', _precision = 6, _arrays = 0x0}, _vptr. =
0x0},
  _vb.ios = 0x8049834}
(gdb)

Monotonically increasing by 8 bytes (I did it a few more times).

Sure looks like we aren't pushing the right thing.

But it certainly didn't give the error you report.

So i don't know what to tell you.


>
> >
> > The current crappy development environment must be very harmful for
> > the cause of those trying to develop free software for linux.  I know
> > it's holding us back.

Oh, and a lot of developers Linux has gained are used to examine only
debuggers, and thus, don't notice when things are broken like calling
virtual functions, becaues they don't call functions.

What is holding you back is the fact that those in the cause of those
trying to develop free software don't seem to want to help develop gdb at
all when it comes to C++ support.
I invite you to actually do something about the "current crappy
development environment", by helping out. I'd be more than glad for some
help.  I certainly can't do it all alone.


> >  HTH,
>  Dan
> >
> > 	David Dill
> >
>
>